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

Abstract

The application provides a memory hot plug control method of a server non-aware security container and an electronic device. The method comprises the following steps: when a memory allocation request initiated by a container process is received, allocating memory from a movable area based on CZone; and when a function container allocation request is received, calling CZone based on RunD-V to perform vertical expansion of the container. The application provides an effective memory hot plug technology, minimizes performance decline during dynamic memory allocation, realizes that multiple copy containers of a function can be vertically expanded in a single VM to reduce the additional memory overhead of the VM, speeds up the runtime startup, can provide technical support for high-density deployment and high-concurrency startup of server non-aware computing, can build a server non-aware computing system with commercial significance based on a hybrid resource expansion technology, and provides a container efficient expansion service 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 solely 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 scaling (i.e., "horizontal expansion" or "scale-out"), while leveraging secure containers to dynamically allocate resources. In this case, each container occupies its own 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 providers have introduced microVM templates to minimize memory usage across guest instances, such as RunD, a lightweight secure container. Template technology enables guest kernels to load memory on demand, allowing code segments and read-only data segments to be shared across multiple microVM instances. Kernel files in the template do not occupy physical memory if not accessed, thus reducing the instance's memory footprint. Using this technology, RunD significantly reduces the memory footprint of newly created microVMs when secure containers are scaled out.

[0004] In addition, there is a significant 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 templates, 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, and it has significant potential to improve resource efficiency during high-concurrency startup and high-density deployment in Serverless environments.

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

[0006] The above limitations prompt those skilled in the art to consider a dynamic MCPV model. In this model, the microVM can adjust its memory size and container number according to fluctuating workloads. When function requests are sparse, the microVM can minimize its container capacity to 1, thereby avoiding memory fragmentation caused by pre-allocated 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 across multiple containers. When the load decreases, the container processes exit 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 problems of memory fragmentation and waste.

[0007] SUMMARY

[0008] In view of the above-mentioned disadvantages of the prior art, the purpose of the present application is to provide a memory hot-plug control method for server-agnostic secure containers and an electronic device, which is used to solve the above-mentioned disadvantages 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 server-agnostic secure containers, which comprises: allocating memory from a movable area based on CZone when receiving a memory allocation request initiated by a container process; and calling CZone based on RunD-V to perform vertical expansion of containers when receiving a function container allocation request.

[0010] In an embodiment of the present application, the memory allocation from the movable area based on CZone comprises: configuring CZone as an agent of the movable area; when receiving a memory allocation request initiated by a container process, the memory allocation request is proxied to CZone; detecting whether the CZone meets the memory allocation request, and allocating memory from the movable area when the CZone fails to meet 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 a value of the CZone ID field based on a correlation with CZone; and upon receiving a memory allocation request initiated by a container process, 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, generates an initial container, and hot-inserts 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, while RunD-V locates the lightweight cgroup attached to the microVM, and increases resource restrictions according to the specifications of the container; RunD-V notifies the agent in the microVM to add the initial container to its scheduling group during runtime 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, it allows CZone to perform container vertical expansion, and when CZone performs container vertical expansion, the state of the CZone flag is changed.

[0015] In one embodiment of the present application, when RunD-V detects that the number of times that an expansion request is rejected reaches a preset value during runtime, 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 object and other related objects, the present application also provides an electronic device, comprising 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-agnostic secure container.

[0019] As described above, the memory hot plug control method of the server-agnostic secure container and the electronic device of the present application have the following advantages

[0020] Advantages:

[0021] The present application provides an effective memory hot plug technology, minimizes performance degradation during dynamic memory allocation, enables multiple copy containers of functions to reduce additional memory overhead of VM through vertical scaling within a single VM, speeds up runtime startup, can provide technical support for server-agnostic computing applications in high-density deployment and high-concurrency startup, can build a server-agnostic computing system with commercial significance based on hybrid resource expansion technology, and provide container efficient expansion services for cloud service providers. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0023] Figure 1 A schematic diagram showing the priority order problem of MicroVM container recycling memory pages in the prior art;

[0024] Figure 2 A schematic diagram showing the memory mixed layout and memory migration problem caused by MicroVM using virtual memory devices in the prior art;

[0025] Figure 3 A schematic diagram showing the overall flow of the memory hot plug control method of the server-agnostic secure container in an embodiment of the present application;

[0026] Figure 4 A schematic diagram showing the CZone organization architecture in the kernel in the memory hot plug control method of the server-agnostic secure container in an embodiment of the present application;

[0027] Figure 5 A flowchart showing the memory allocation from the removable area based on CZone in the memory hot plug control method of the server-agnostic 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 memory hot-plug control method for 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 in a server-unaware secure container in an embodiment of the present application;

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

[0031] The following describes the implementation of this embodiment through specific examples. Those skilled in the art can easily understand the other advantages and effects of this embodiment from the content disclosed in this specification. This embodiment can also be implemented or applied through different specific implementations. The details in this specification can also be modified or changed 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 unless there is a conflict.

[0032] Efficient memory hot-plugging of microVMs is crucial to enable 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 typically avoid acquiring all memory at the outset, and instead allocate memory on demand as it is used, which is also known as demand paging. Therefore, there are actually two types of free memory in the guest: one is memory that has never been used by a container and does not occupy any physical RAM (non-dirty pages), and the other is memory that is marked as free after being released by a 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. This problem is particularly evident when the microVM is scaled down. This problem can be solved by Figure 1 To illustrate. Figure 1In the figure, white blocks represent guest memory that has never been used, gray blocks (units 1, 2, 6, and 7) represent guest memory that was once used but is now idle due to container reclaim, and blue blocks (units 3 and 4) represent memory blocks that are currently in use. In this case, units 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 blocks (5 and 8) as offline candidates because these blocks are unused and indistinguishable from the gray blocks from the guest's perspective. Therefore, when they choose to unplug the white blocks, the guest believes that a certain amount of memory has been freed, but the actual memory reclaimed on the host side does not correspond, resulting in inconsistent reclaim effects between the host and guest.

[0034] In the dynamic MCPV model, using virtio memory offloading results in a large number of unallocated pages that cannot be returned to the host, resulting in a continuous occupation of memory space. This continuous occupation reduces the host's memory available for resource provisioning, thereby reducing memory utilization.

[0035] ACPI (Advanced Configuration and Power Interface) is an open industry standard developed by a number of software and hardware companies. It enables software, hardware, operating systems (OSs), motherboards, and peripheral devices to manage power usage in a specific manner. Hot-Plug events generated by system hardware allow the operating system to directly control plug-and-play devices from the user's perspective, unlike previous direct BIOS-based management. 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 portion of 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 results in a mixed memory layout. For example, suppose three containers A, B, and C are started simultaneously in a microVM, as shown in Figure 2As shown in Figure 1. In the first phase, three containers and their processes were created at time t0 and began consuming memory. This simultaneous startup caused these containers to allocate memory concurrently. Each container was allocated three memory blocks to meet its specifications, for a total of nine memory blocks allocated to the guest. As a result, all container processes received the required memory, and all memory devices became dirty and partially occupied by the three container processes. Because the buddy allocator lacked information about the ownership of these memory devices, it indiscriminately satisfied these memory allocation requests, resulting in interleaved use 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 reclaimed and its memory blocks are released in the second phase, the microVM begins returning memory device B to the host at time t6. At this point, two memory blocks, one from container A and one from container B, coexist on memory device B. If the microVM plans to remove memory device B, memory migration becomes a problem. This process requires migrating the two memory blocks to free space on other memory devices, which consumes memory bandwidth and significantly impacts the performance of containers A and C.

[0038] If ACPI memory resizing is used in a dynamic MCPV model, memory bandwidth can become a significant bottleneck. This can significantly increase the load on the host machine 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 for 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 a container process are placed in a centralized removable memory region, ensuring that all unallocated pages of the current container are also contained in this region. When performing a hot swap operation, this region captures all unallocated pages of the container, facilitating memory reclamation by the host.

[0042] 2) Pages in a 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. Based on CZone, we also designed RunD-V, a secure container memory hybrid scaling system that provides both horizontal and vertical resource expansion.

[0044] The following will elaborate in detail the principles and implementation methods of the memory hot-swap control method and electronic device of the server-unaware security container of this embodiment, 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] This 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 the memory hot-plug control method of the server-unaware secure container in an embodiment of the present application; Figure 3 As shown, the method includes:

[0046] Step S100, upon receiving a memory allocation request initiated by a container process, allocating memory from the removable 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 RunD-V, a CZone-based secure container memory hybrid scaling system. The core of the invention is the design of secure container memory hot-swappable technology and system software for server-aware computing scenarios.

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

[0050] Step S100: When a memory allocation request initiated by a container process is received, memory is allocated from the 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 of the memory hot-plug control method of the server-unaware secure container in one embodiment of the present application; Figure 4As shown, these regions are arranged in order, with regions with lower indices being more general and versatile. When allocating memory, the operating system assigns a region index to each request, indicating the preferred region where the requested memory should reside. If the current region cannot satisfy the request, Linux explores regions with lower indices to meet the need. By dividing memory into distinct regions and prioritizing memory allocation based on region index, Linux optimizes memory usage, ensuring that critical system functions, particularly those involving hardware interaction, access 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 this end, CZone extends the design of the Linux Movable Zone (MovableZone). The 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 the 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 viewed as an adaptive Movable Zone with a higher zone index. Multiple CZones are organized into an array, such as Figure 1As shown in Figure 1, the kernel maintains two types of memory regions: movable zones and Czones. Similar to movable zones, Czones are pre-compiled with the kernel and memory is allocated and released dynamically. Czones act as proxies for movable zones. Assuming a container process is assigned to a Czone, when it requests memory from a movable zone, the request is first proxied to the Czone. If the Czone cannot satisfy the memory request, the system will directly attempt to allocate memory from the movable zone without considering other Czones.

[0058] When a user-space program intends to spawn a new container process, it usually triggers a fork() system call to the kernel. Upon invocation, fork() copies the attributes of the invoking process to spawn an identical copy, called child process. Although the parent and child processes maintain separate memory spaces, they initially share the same memory content due to the on-demand paging mechanism. Therefore, in order to confine the memory of a particular process within a designated Czone, it is necessary to redirect all memory allocation requests of that process to the corresponding Czone.

[0059] In an embodiment of the present application, the allocating memory from the movable zone comprises: configuring a CZone ID field in a task structure of Linux, and configuring a value of the CZone ID field based on the correlation with the CZone; upon receiving a memory allocation request initiated by a container process, allocating memory from the movable zone based on the value of the CZone ID field.

[0060] In an 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 a wrapper system czone_fork().

[0061] In the embodiment, a new integer field, CZone ID (CID), is introduced in the task structure of Linux. For standard processes that are not associated with CZone, the field is set to zero by default. However, for processes that are confined within a particular CZone, the field is set to the ID of the corresponding CZone. By default, this field is inherited by child processes, thus ensuring that a process cannot exceed the boundaries of its target CZone by creating child processes. Developers can create new processes that are confined within a particular CZone using a simple wrapper system czone_fork(). Upon invocation, czone_fork() sets the CZone field in the task structure of the child process to the provided CZone ID, thus effectively enforcing the confinement within the designated 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 procedure. 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 checks the movable area directly. Therefore, the buddyallocator ensures that processes with non-zero CZone IDs use pages from the target CZone first.

[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 currently the most advanced secure container scale-out runtime system in academia. When introducing a CZone-based scale-up mechanism on top of this scale-out mechanism, a global strategy must be designed to maximize the benefits of both scaling approaches. A simple approach is a "scale-up first" strategy, which prioritizes filling a single VM before scaling out to the next one. When fluctuations in function requests don't require frequent container scaling, this approach can leverage the low memory overhead of scale-up to 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, generates an initial container, and hot-inserts 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, while RunD-V locates the lightweight cgroup attached to the microVM, and increases resource restrictions according to the specifications of the container; RunD-V notifies the agent in the microVM to add the initial container to its scheduling group during runtime to complete the vertical expansion.

[0066] When multiple function container copies coexist in the same RunD-V sandbox through the CZone mechanism, managing resource contention between container processes presents a significant challenge. In addition to memory, other resources such as CPU and network also need to be hot-swappable 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 the 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 scaling by calling CZone to hot-insert the required memory region for the container (step 1). 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 region is then bound to the container ID and recorded in CZone while the container remains paused in the background (step 2). Third, the agent calls the guest cgroup to limit CPU and memory usage and attaches these limits to the container process (step 3). This separation ensures that resource management within the guest can be handled independently without placing additional burden on the host cgroup. Simultaneously, RunD-V locates the lightweight cgroup attached to the microVM and increases resource limits based on the container's specifications (step 4). Finally, the RunD-V runtime notifies the agent in the microVM to add the new container to its scheduling group, completing the vertical scaling (steps 5 and 6).

[0068] However, when high concurrency requires massive scaling of function containers, using only vertical scaling is not optimal. First, the use of mutexes in Linux memory management can significantly degrade concurrent hot-plugging of memory within a virtual machine. Second, there is a limit to the number of vertical scaling units that a single virtual machine can support (e.g., 8). When concurrency demands exceed this limit, the system falls back to the more expensive horizontal scaling approach. Therefore, there is a trade-off: taking advantage of the higher density provided by vertical scaling at the expense of a certain degree of concurrency.

[0069] Based on the above analysis, the vertical expansion principles 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 scaling occurs more frequently, it indicates a need to leverage horizontal scaling capabilities to scale vertically across multiple scaled virtual machines.

[0072] In one embodiment of the present application, when RunD-V detects that the number of times that an expansion request is rejected reaches a preset value during runtime, 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 it allow the request 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 detects that this expansion request is rejected, it triggers the creation of a new microVM instance, a horizontal expansion of RunD-V, which scales resources in parallel with the existing microVM instance. This allows us to overlap horizontal and vertical expansion, achieving 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 Shown is a schematic diagram of the implementation process of the memory hot-plug control method of the server-unaware secure container in an embodiment of the present application; 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: This is a function of the RunD-V function management module that receives different function requests and routes them to the instance manager of the function.

[0078] 2) Function Instance Manager: This is a function within RunD-V's function management module. It manages all container instances created by a function and manages the request reuse and lifecycle of all containers. It allocates an available container to a function request. If no free container exists, it triggers the resource expansion module to create a new container. If a managed container instance remains idle for a certain period of time, it triggers the resource management module to reclaim resources vertically or horizontally.

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

[0080] 4) Horizontal Resource Scaling: This is a feature of RunD-V's resource scaling module. This module implements horizontal scaling based on existing Serverless resource scaling logic while integrating CZone core functionality to create new microVM instances for vertical scaling.

[0081] 5) Vertical Resource Scaling: This is a feature of RunD-V's resource scaling module. This module leverages the CZone kernel functionality to dynamically create multiple containers within a microVM. Each container is isolated using its own memory domain, while all containers share the same guest OS overhead.

[0082] 6) Resource Recycling: This is a function of RunD-V's resource scaling module. Based on resource recycling requests sent by the function management module, this module triggers horizontal resource recycling (deleting MicroVMs) and vertical resource recycling (deleting containers within microVMs and hot-plugging memory devices).

[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 processes, 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 memory device information and function container processes.

[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 uninstalled, instructing the CZone-based guest kernel to hot-unplug the memory.

[0089] like Figure 8 As shown, the protection scope of the memory hot-plug 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. All solutions implemented by adding, reducing, or replacing steps in the existing technology 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, it implements the memory hot-plug control method of the server-unaware security container provided in any embodiment of the present application.

[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 component, or any combination of the above. More specific examples of computer-readable storage media (a non-exhaustive list) 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 that can be used by an instruction execution system, device or 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 diagram of an electronic device 100 provided in an embodiment of the present application. In some embodiments, the electronic device can 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 this application can also be applied to databases, servers and terminal artificial intelligence-based service response systems. The embodiment of this 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 an 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, magnetic disk, USB flash drive, memory card or optical disk, etc., various 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 that 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-plug control method of the server-unaware security 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 interactive interface related to the memory hot-swap control method of the server-unaware secure container.

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

[0100] The above embodiments are merely illustrative of the principles and effects of the present embodiments and are not intended to limit the present embodiments. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of the present embodiments. Therefore, all equivalent modifications or alterations made by persons skilled in the art, including those of ordinary skill in the art, without departing from the spirit and technical concepts disclosed in the present embodiments shall be covered by the claims of the present embodiments.

Claims

1. A method for controlling hot-swap memory in a server-unaware secure container, characterized by: The method comprises: Upon receiving a memory allocation request initiated by a container process, memory is allocated from a removable zone based on CZone. The removable zone is a Linux removable zone, which is a memory zone used for memory compression, defragmentation, and migration tasks. In the CZone organizational structure, Linux organizes memory into several zones. These zones are arranged in order, with zones with lower indexes being more general and versatile. When allocating memory, the operating system assigns a zone index to each request, indicating the preferred zone where the required memory should reside. If the current zone cannot satisfy the request, Linux explores zones with lower indexes to satisfy the request. Upon receiving a function container allocation request, CZone is called based on RunD-V to perform vertical container expansion. RunD-V is an expansion method that introduces a vertical expansion mechanism based on CZone into the horizontal expansion runtime system of secure containers. RunD-V is a hybrid scaling system for secure container memory. 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; detecting whether the CZone satisfies a memory allocation request, and allocating memory from the movable area when the CZone cannot satisfy the memory allocation request; 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 an 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. RunD-V locates the lightweight cgroup attached to the microVM and adds resource limits based on 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 vertical expansion.

2. The method for controlling hot-swap memory in a server-unaware secure container according to claim 1, wherein: Allocating memory from the movable area includes: Configure the CZone ID field in the Linux task structure and configure the value of the CZone ID field based on the correlation with the CZone; When a memory allocation request initiated by a container process is received, memory is allocated from the movable area based on the value of the CZone ID field.

3. The memory hot-swap control method of a server-unaware secure container according to claim 2, 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(); the czone_fork() sets the CZone field in the task structure of the child process to the provided CZone ID, thereby constraining it within the specified CZone.

4. The memory hot-swap control method of a server-unaware secure container according to claim 1, characterized in that: Also includes: RunD-V configures a CZone flag and the initial state of the CZone flag in each microVM 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.

5. The method for controlling hot-swap memory in a server-unaware secure container according to claim 4, wherein: When the number of rejected extension requests during RunD-V runtime detection reaches a preset value, it triggers the creation of a new microVM instance to perform horizontal expansion of RunD-V.

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

7. An electronic device, characterized in that: include: including 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 secure container as described in any one of claims 1 to 6.

8. 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 secure container are implemented as described in any one of claims 1 to 6.

Images