CN116126471A

CN116126471A - Container creation processing method, system, electronic device, and readable storage medium

Info

Publication number: CN116126471A
Application number: CN202310032183.4A
Authority: CN
Inventors: 马腾; 张宁; 丁宁; 刘峥
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2023-01-10
Filing date: 2023-01-10
Publication date: 2023-05-16

Abstract

The application discloses a container creation processing method, a system, an electronic device and a readable storage medium, wherein the method comprises the following steps: a first node reads data of a container stored in a shared memory from the shared memory, wherein the data of the container is written into the shared memory by other nodes in the process of creating the container, the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the first node and the other nodes; the first node creates a new container using the read data of the container. The method and the device solve the problem of reduced service quality caused by longer time for creating the container in the related technology, further shorten the creation time of the container, and share and use the container data, have good resource utilization rate and provide service quality.

Description

Container creation processing method, system, electronic device, and readable storage medium

Technical Field

The present application relates to the field of cloud computing, and in particular, to a container creation processing method, a system, an electronic device, and a readable storage medium.

Background

The function computation is an event-driven full-support computing service. By using function calculation, the user does not need to purchase and manage infrastructure such as a server, and only needs to write and upload passage codes. The function calculation prepares the calculation resources for the user, runs tasks flexibly and reliably, and provides the functions of log inquiry, performance observation, alarm and the like. I.e., function computation abstracts resource management from the developer's perspective. The developer need only write the application programs as functions in a popular programming language, upload the functions to the function computing platform, and specify how to call them. The platform may process each call by dynamically generating a container to automatically expand upon a function request. The generated container is automatically recovered after the function is returned. The function computation mode can save computation resources, and a developer only needs to pay for the container in use.

The container is needed in function calculation, and can be started from a physical machine. The current common model is to create containers step by step through templates, a process called cold start. During a cold start, it is necessary to set the configuration of the setup container and initialize the runtime language environment, which steps can be delayed (typically on the order of hundreds of milliseconds). In practical use, however, most of the container lifecycle is relatively small (typically less than 20 milliseconds) with respect to delay, which results in a relatively long container start-up (also called creation) time, resulting in a reduced quality of service for services requiring use of the container (e.g., function calculations).

Disclosure of Invention

The embodiment of the application provides a container creation processing method, a system, an electronic device and a readable storage medium, which are used for at least solving the problem of service quality reduction caused by longer time for creating a container in the related technology.

According to one aspect of the present application, there is provided a container creation processing method including: a first node reads data of a container stored in a shared memory from the shared memory, wherein the data of the container is written into the shared memory by other nodes in the process of creating the container, the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the first node and the other nodes; the first node creates a new container using the read data of the container.

According to another aspect of the present application, there is also provided a container creation processing method, including: creating a container by the node; the node writes the data of the container into a shared memory in the process of creating the container, wherein the data of the container stored in the shared memory can be read by other nodes, the data of the container is used when the other nodes create new containers after being read, and the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the nodes and the other nodes.

According to another aspect of the present application, there is further provided a container creation system, including a plurality of nodes sharing a shared memory, where the plurality of nodes are connected to a computing fast connection CXL switch and connected to the shared memory through the CXL interacting machine, and the plurality of nodes include a node for executing the method steps described above and a first node.

According to another aspect of the present application, there is also provided an electronic device including a memory and a processor; wherein the memory is configured to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to perform the method steps described above.

According to another aspect of the present application, there is also provided a readable storage medium having stored thereon computer instructions which when executed by a processor perform the above-mentioned method steps.

In the embodiment of the application, a first node is adopted to read data of a container stored in a shared memory from the shared memory, wherein the data of the container is written into the shared memory by other nodes in the process of creating the container, the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the first node and the other nodes; the first node creates a new container using the read data of the container. When the node needs to create the container, the data of the container are directly obtained from the shared memory and used when the container is created, that is, the data are multiplexed, and the data are directly used without regenerating the data, so that the creation time of the container is shortened, that is, the starting time of the container is also faster. In summary, the problem of reduced service quality caused by longer time for creating the container in the related technology is solved, so that the creation time of the container is shortened, the container data is shared, the resource utilization rate is good, and the service quality is provided.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application, illustrate and explain the application and are not to be construed as limiting the application. In the drawings:

FIG. 1 is a flow diagram of a containerized application according to the related art;

FIG. 2 is a flow chart diagram of a container creation process method according to an embodiment of the present application;

FIG. 3 is a second flowchart of a container creation process method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a container start-up employing CXL according to an embodiment of the present application; the method comprises the steps of,

fig. 5 is a schematic illustration of container preparation and activation according to an embodiment of the present application.

Detailed Description

It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

It should be noted that the steps illustrated in the flowcharts of the figures may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is illustrated in the flowcharts, in some cases the steps illustrated or described may be performed in an order other than that illustrated herein.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

In the following embodiments, the technology such as a container will be referred to, and technical terms relating to the following embodiments will be first described.

DRAM

A dynamic random access memory (Dynamic Random Access Memory, abbreviated as DRAM) is a semiconductor memory, and the main principle of operation is to use the magnitude of stored charges in a capacitor to represent whether a binary bit (bit) is 1 or 0. In reality, the transistor has a leakage current, so that the amount of charges stored in the capacitor is insufficient to accurately determine the data, and the data is damaged. Thus, for DRAM, periodic charging is an unavoidable requirement. This feature of requiring timed refresh is referred to as "dynamic" memory. In contrast, a static memory (SRAM) does not lose memory even if it is not refreshed after storing data. Based on the specific DRAM, DRAM is generally used as a memory in a physical machine.

CXL

Computing quick connect (Compute Express Link, abbreviated CXL) is an open industry standard for high bandwidth low latency device interconnection. As an interconnect protocol for cache coherency, it aims to help a system (especially one with accelerators) to operate more efficiently. It may be used to connect processors (Central Processing Unit, abbreviated as CPU) and accelerators (accelerants), memory buffers (Memory buffers) and Smart cards (Smart NIC) etc. types of devices, even in machine learning and high performance computing scenarios. CXL multiplexes three types of protocols, cxl.io (input/output), cxl.cache (cache), cxl.memory (memory), on the basis of a high-speed serial computer expansion bus (Peripheral Component Interconnect Express, abbreviated PCIe) 5.0. Cxl.io is a protocol for initializing, linking, snooping devices and enumerating and registering accesses. It provides a non-coherent load/store interface for input-output (I/O) devices, similar to PCIe Gen5. Cache is a protocol that defines interactions between a host (typically a CPU) and a device (e.g., a CXL memory module or accelerator), which allows CXL devices to access data cached in host memory with low latency. The CXL.memory is responsible for resolving accesses by the processor to memory within the device, and the CXL maintains consistent memory space between the CPU and the device.

Function calculation

The function computation is an event-driven full-support computing service. By using function calculation, the user does not need to purchase and manage infrastructure such as a server, and only needs to write and upload passage codes. The function calculation prepares the calculation resources for the user, runs tasks flexibly and reliably, and provides the functions of log inquiry, performance observation, alarm and the like. I.e., function computation abstracts resource management from the developer's perspective. The developer need only write the application programs as functions in a popular programming language, upload the functions to the function computing platform, and specify how to call them. The platform may process each call by dynamically generating a container to automatically expand upon a function request. The generated container is automatically recovered after the function is returned. The function computation mode can save computation resources, and a developer only needs to pay for the container in use. The container is the smallest unit to perform computing tasks, and by using the container not only packages dependencies of applications, it can simplify the deployment of functions, but also can provide lightweight isolation, which is necessary to run function computing tasks in a multi-tenant environment.

Container

An Application program (APP) or a function needs to be supported by an operating environment such as an operating system in the running process, so that the Application or the function can be packaged for running in different environments. A so-called container is a software package that provides a complete runtime environment for applications or functions deployed within the container, and may include, for example: code for an application or function, related configuration files, libraries, dependencies required to run an application or function, and the like. Containerization is an application or system distribution method that isolates applications or functions and their dependencies from the underlying infrastructure. It is an operating system level virtualization that allows a user to deploy and run applications or functions in a container without having to launch an entire virtual machine for each application or function.

Fig. 1 is a schematic flow chart of a containerized application according to the related art, as shown in fig. 1, the flow chart includes the steps of:

and (1) writing Application (APP) or function codes.

Step (2) a container file (Dockerfile) is created, which contains the description of the current application, the dependencies and how the application or function is run. It should be noted that, in the following embodiments, the container may be implemented by using a Docker technology, or may be implemented by using other container technologies.

And (3) executing a build container mirror (Docker image build) command on the Dockerf file.

Step (4), pushing the Docker mirror image to a container Host (Docker Host).

Step (5), the Docker mirror image on the container host operates as a container or as a service.

Container activation

In function computation, the container needs to be started from the physical machine, thereby introducing the cost of function starting and the cost of state transition caused by isolating the address space. The current common model is to create containers step by step through templates, a process called cold start. The entire steps include pulling the container view, setting the configuration of the container, and initializing the runtime language environment, which can introduce delays on the order of hundreds of milliseconds. However, in practical applications, most containers have a life cycle of less than 20 ms, and the python (a programming language) runtime environment for creating containers by RUNC (for creating containers according to standard specifications) requires a second-level delay, and in the case of Java virtual machine (Java Virtual Machine, JVM) environment, the time required is longer.

In order to solve the problem of long cold start time of the container, in an alternative embodiment, a hot start mode is provided, in which a plurality of container instances are created in a local memory in advance in the hot start mode, or the container created before is reused and cached in the memory, and a fast start mode is supported by directly activating the cached container instances. Since this scheme requires creating multiple container instances in memory, a lot of memory resources are consumed, and it is difficult to predict the demand for containers by function calculation, resulting in a waste of resources. In the case of a richer memory resource and a more deterministic type of container used, a hot start approach may be employed.

In another alternative embodiment, a copy-on-copy (fork) scheme is also provided, wherein the fork function is used to divide the running program into 2 nearly identical processes, each of which starts a thread that starts executing from the same location in the code. The threads in both processes continue to execute as if both users initiated both copies of the application. In this approach, only one container is cached in memory as a parent container instance, and fork is used to create child containers from the parent container by expanding the fork semantics of the operating system.

The container may be started using a checkpoint recovery approach in addition to the one described above. The method of checkpoint recovery can set a checkpoint in a running container, save the state of the checkpoint to a disk, and recover the container by using the saved data when the container needs to be recovered. The checkpoint recovery (C/R) approach is to launch a container from a container checkpoint stored in a file. It requires only O (1) (representing the lowest spatiotemporal complexity, the consumed resources are independent of the size of the input) resources (or files) to be hot-started. This way of checkpointing and restoration, while good in terms of resource usage, may be somewhat slower than the way in which checkpoints are restored, e.g., the way in which hot starts and Fork are slower than the way in which cold starts are due to the need for file system operations and serialization (saving the state corresponding to checkpoints in disk) of the reverse serialization (restoring the state corresponding to checkpoints saved in disk).

Function computation services also exist that span multiple physical nodes, creating a parent container instance from one of the physical nodes (i.e., the physical machines), which may require the same physical machine to create the parent container instance, so that it can be hot-started by way of checkpoint recovery. The container instance is created first, then stored in the distributed file system after serialization, and for any physical machine, the data needs to be read out from the HDFS first, and then deserialized for recovery. The time consumption of creating a container by checkpoint recovery may be reduced in the process of reading data from the distributed file system, and if the time consumption of the process may be reduced, the startup time of the container may be shortened.

In order to solve the above-described problems, a container creation processing method is provided in the following embodiment, fig. 2 is a flowchart of a container creation processing method according to an embodiment of the present application, and as shown in fig. 2, steps involved in the method in fig. 2 are described below.

In step SA02, a node reads data of a container stored in a shared memory from the shared memory, wherein the data of the container is written into the shared memory by other nodes in the process of creating the container, and the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the node and the other nodes. The functionality provided by a container may be configured as desired herein, e.g., the container may be used to provide a complete runtime environment for applications or functions configured within the container.

In this step, a node is referred to as a first node, which is one of a plurality of nodes, and in order to distinguish between nodes using container data and nodes storing container data in a shared memory, in fig. 2, the node using container data is referred to as a first node, and "first" is used herein for convenience of description only and does not constitute any other limitation on the node. A node sharing a memory may be understood as an entity having a computing resource (such as a CPU, a memory, etc.) capable of creating and running a container, and the entity may be a real device, such as a physical machine, or may be a virtual machine, etc., and in the following embodiment, for convenience of description, a physical machine (also referred to as a physical node) is used as an example for illustration, it should be noted that a physical machine in the following embodiment may also exist in other manners, such as a virtual machine, etc.

From this step, it is known that in the method shown in fig. 2, an architecture is provided in which all nodes that need to generate the same container may share a memory, where the same container may be a container for accommodating the same application or a container for providing the same service. For example, if multiple containers are used to configure the A application, then the containers may be understood to be the same container. For another example, if multiple containers are used to provide the function computation of the B function, then these containers may also be understood as the same containers. Many of the data of these containers accommodating the same application or containers providing the same service are the same, such as Runtime (run time) or functions provided by the containers. Thus, these data can be directly multiplexed at the time of creating a new container.

In step SA04, the node creates a new container using the read data of the container. Alternatively, the new container created may be run in the local memory of the node.

In this step, when the first node needs to create the container, the data of the container is directly obtained from the shared memory and used at the time of creating the container, that is, the data is multiplexed (also referred to as multiplexing of the data in the following description), and since the data is directly used without regenerating the data, the creation time of the container is shortened, that is, the start-up time of the container is also faster, and therefore, the problem of reduced service quality caused by the longer time of creating the container in the related art is solved by the above steps, and the creation time of the container is shortened, and the service quality is provided.

It should be noted that the number of nodes using the shared memory may be very large, and the types of containers to be created on each node may be very large, so the data of the containers stored in the shared memory may not be just the data of one container. For example, nodes using shared memory are: node 1, node 2, node 3, node 4 and node 5. Wherein node 1 creates a container 1 for providing function computation of B-functions, where node 1 may save the data of container 1 in shared memory; node 2 creates container 2 for accommodating application a, where node 2 may also save the data of container 2 in shared memory, and node 3 may acquire the data of container 1 for multiplexing to create a new container when it is necessary to create a container for providing function computation of B function; when a container for accommodating the application a needs to be created, the node 4 can acquire the data of the container 2 for multiplexing to create a new container; when the node 5 needs to create the container 3 for accommodating the C application, the node 5 starts to create the container 3 if no data of the container 3 is found in the shared memory, and may also save the data of the container 3 in the shared memory during the process of creating the container 3. That is, the data of different types of containers may be stored in the shared memory, and the node may first determine whether the shared memory stores the data of the type of container when creating the predetermined type of container, if so, acquire the data to multiplex to create a new container, if not, perform a normal container creation process, and store the data of the type of container in the shared memory during the process of creating the container.

In the above steps, a shared memory is used, which is located outside of the plurality of nodes, and each node has its own memory, hereinafter, for the purpose of distinguishing, the memory in the node is referred to as (local memory), and the memory located outside the node and shared by the plurality of nodes is referred to as remote memory or shared memory. The purpose of using shared memory is to make the reading of data faster, and therefore the method shown in fig. 2 creates containers faster. In addition to faster speeds, shared memory and local memory may also be mapped, i.e., the shared memory is mapped to each of the plurality of nodes, the shared memory mapped on each node being located in a fixed memory address space in each node. By the method, a plurality of nodes of the shared memory can read and write from the shared memory more easily.

For example, the node reading the data of the container from the shared memory may include the steps of: the node obtains the memory address space of the shared memory mapping in the local memory from the local memory of the node; the node copies the container's data from the memory address space to the local memory. By way of example, after mapping the shared memory to the node's local, the node may use the shared memory as if it were local memory.

After the shared memory is used, since a plurality of nodes can read and write the shared memory, the possible conflict can be prevented by setting a read-write lock in order to prevent the conflict. But off-the-shelf protocols may also be introduced to manage shared memory. That is, in an alternative embodiment, the plurality of nodes are connected to a computing fast connect CXL switch and to the shared memory through the CXL interactive machine. Through this alternative embodiment, CXLs may be introduced to manage shared memory.

As can be seen from the above alternative embodiments, the shared memory may be used to store data that can be reused when creating the same container, and when multiplexing these data to create a new container, the new container may be created by using the read data of the container by the multiplexing Fork function. The new container created using the Fork function may be a child container of the container. This way of creating new containers is relatively easy to implement and can be supported by most systems.

In addition to storing data that can be multiplexed when creating the same container, the shared memory may store other data that can be shared by containers, where the data may be modified by each container, where a corresponding amount of data may be copied according to the number of containers, that is, ensuring that each container corresponds to one piece of data, where this processing manner may cause a waste of the shared memory, in another alternative embodiment, after the first node creates the new container, the data that is shared by the container and the new container is stored in the shared space, and where the first node copies a portion of the shared data that needs to be modified when the new container modifies the shared data; the first node modifies the copied part of the data needing modification, and stores the modified data in the shared space. By the alternative implementation mode, only when the public data is modified by other containers, the modified partial data is copied, and the space of the shared memory is saved.

The above alternative embodiments are described in terms of nodes that create new containers from reading data of containers in the shared memory, and the following alternative embodiments are described in terms of nodes that create containers and save data of containers to the shared memory. It should be noted that, a plurality of nodes of the shared memory may have both functions, that is, a function of writing data of the container into the shared memory when creating the container and a function of multiplexing and creating a new container when reading data of the container from the shared memory. Fig. 3 is a second flowchart of a container creation processing method according to an embodiment of the present application, and as shown in fig. 3, steps involved in the method in fig. 3 are described below.

In step B02, the node creates a container.

In this step, the node may first determine whether the shared memory stores data of the type of container, and if so, acquire the data for multiplexing to create a new container, and if not, perform a normal container creation process, and store the data of the type of container in the shared memory during the container creation process.

And step B04, the node writes the data of the container into a shared memory in the process of creating the container, wherein the data of the container stored in the shared memory can be read by other nodes, the data of the container is used (or called multiplexing) when the other nodes create new containers after being read, and the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the node and the other nodes.

By this step, the data of the container is stored in the shared memory when the container is created, so that the data can be multiplexed, the speed of creating the container of the same type by other nodes is increased, and the speed of reading and writing the data is also increased due to the use of the shared memory.

As discussed above, the shared memory is also beneficial in that it can be mapped onto each of the plurality of nodes, the shared memory mapped onto each node being located in a fixed memory address space in each node. Thus each node can use shared memory as local memory.

For example, the node writing the data of the container to the shared memory during the process of creating the container may include the following steps: the node obtains the memory address space of the shared memory mapping in the local memory from the local memory of the node; the node writes the data of the container into the memory address space.

Corresponding to fig. 2 and 3, in an alternative embodiment a container creation system may also be provided, comprising a plurality of nodes, wherein a plurality of nodes comprise nodes capable of performing the steps in fig. 2, nodes capable of performing the steps in fig. 3, or each node is capable of performing the steps in fig. 3 and 3. Optionally, a CXL interacting machine, i.e. the plurality of nodes are connected to the CXL switch and to the shared memory via the CXL interacting machine, may also be included in the system.

The alternative embodiments described above may be used for various cloud services requiring a container to be started, for example, containers created by multiple nodes described above may be used to provide a function computation service. Function computation as a service important on the cloud can shorten the start-up time and improve the service quality after using the method in the alternative embodiment. The following describes an alternative embodiment using function calculations as an example. In the following optional embodiments, the characteristics of supporting the sharing of memory resources in the rack by CXL are utilized to share the parent container between different physical machines, so that the occupation of the memory resources is reduced, and the starting time is shortened.

Fig. 4 is a schematic diagram of container startup using CXL according to an embodiment of the present application, and in fig. 4, although three physical nodes (i.e., physical machines) are shown, two physical nodes or more physical nodes may be used, and in each of physical node 0, physical node 1, and physical node 2, there is a CPU and a local memory (the memory may be DRAM), and these three physical nodes are connected to a remote memory (i.e., a memory pool in fig. 4, which is located at a remote location with respect to the local memory of each physical node, and thus is referred to as a remote memory in the following embodiments). After the physical node creates a container (VM-0), then saves the container in the remote memory, the physical node 1 and the physical node 2 acquire the container from the remote memory, and then use the container for container (VM-1) and container (VM-2) available.

In another alternative embodiment, the physical container may be further checkpointed, the physical container is mirrored into an image file by setting the checkpoint, the image file is stored in a remote memory, and the physical node 1 and the physical node 2 acquire the image file from the remote memory, and recover the container in the respective local memory according to the image file to obtain a container (VM-1) running in the physical node 1 and a container (VM-2) running in the physical node 2.

In fig. 4, multiple physical nodes are connected to a CXL switch through an upstream port (upstream port), the CXL switch is connected to a remote memory through a downstream port (downstream port), and each physical node has its own local memory. The memory latency of a connection through the CXL is higher than the local memory. The architecture in fig. 4 may be based on the CXL2.0 specification described above (although other versions of the CXL specification may be used as well), and thus is capable of supporting single layer switching (switch) architectures. The architecture can effectively ensure the running of function computing applications in common scenes. The remote memory can be mapped to a plurality of different physical machines through memory mapping and fixed in a specific memory address space, so that the application on the physical machines can access the remote memory through the predetermined addresses. Since CXL supports management of memory sharing, cache coherency issues do not occur for multiple physical machines.

The containers created in physical node 0 are referred to as parent containers in fig. 4, and the containers created in physical node 1 and physical node 2 are referred to as child containers. For creation of child container instances, the partial data may not be able to multiplex data of the parent container instance, for example, some state information and some configuration information related to the physical machine, for example, the information that cannot be multiplexed may include the following four aspects: (1) CPU register state, state to resume execution, etc.; (2) Memory structure related information such as variable address mapping tables (VMAs), page tables, etc.; (3) File descriptor related data that varies for different host physical opportunities; (4) Container related configuration information such as configuration of a group (cgroup) of containers, memory limitations, and/or CPU binding information, etc. For data that cannot be multiplexed with a parent container, each container may use local data.

After the creation of the child container instance is completed, the function calculation task proceeds as normal, and all data is reclaimed by the child container instance locally immediately after completion. For a parent container instance, it may be cached in the memory of the CXL, waiting for the next time the function computation task is started to be multiplexed.

Fig. 5 is a schematic diagram of container preparation and startup according to an embodiment of the present application, and the stage of creating containers on physical node 1 and physical node 2 is divided into two stages in fig. 5: the first phase is the preparation phase and the second phase is the start-up phase. Physical node 0 creates a parent container in the preparation phase and then writes the created parent container to the remote memory, which is maintained and managed by cxl. After writing (Write) the parent container to the remote memory, a startup phase is entered in which both physical node 1 and physical node 2 Read (Read) the parent container from the remote memory and use the Read parent container to generate child containers.

When applying fig. 5 to function computation, the function computation application first needs to confirm the physical machine used to create the parent container instance as the primary node (P), i.e., physical node 0 in the graph, and the process of confirming the primary node can be performed by configuration in a program or by a collaborative protocol. The primary node creates container instances according to normal procedures, including initializing and starting the container, and creation of a runtime environment (java, python, etc.). In the whole creation process, data needs to be stored in a remote memory associated with CXL. Since the remote memory is bound in a specific memory address space, the container data is not swapped out to the external memory. And then in the starting process, the secondary physical machines (namely the physical node 1 and the physical node 2) are used as the working nodes (S) to acquire the positions of the container data, and the data is directly read into the local memory in a memory copy mode. It should be noted here that most of the data read is directly reusable, since the parent container instance is still running, and some of the data is copied by Copy-on-Write (Copy-on-Write), in which way each container needs to use the same resource in the remote memory, and it is not necessary to create a complete Copy of that resource for each container. By sharing this resource by multiple containers, when a container needs to modify a location of the resource, it copies that location to a copy, and then writes the newer content to that copy, which is referred to as a copy-on-write manner, the additional protocol overhead required by the distributed shared memory to maintain cache coherency is reduced.

In fig. 5, a container_pool_create (function for creating containers) operation may be provided in the preparation phase to complete the creation of the parent container instance, and the container_pool_create is an asynchronous function that returns a semaphore after the creation is successful. For the upper-level function computing application, the operating system call of the container_pool_fork (function for the copy container) can be provided in fig. 5 to complete the creation of the new sub-container instance, and the function computing application only needs to change the corresponding position in the code to support asynchronous creation.

Although only 3 physical nodes are shown in fig. 4 and 5, two sub-containers are replicated, if the alternative embodiment described above is applied to a scenario where the function computation requires quick creation of containers, numerous container instances can be created in a short time. The alternative embodiments described above have low latency and high resource utilization compared to creating container instances using either a cold start or a cache, and test results show that build time is as short as 2 microseconds. In contrast, creating a startup function computation instance by remote direct data access (Remote Direct Memory Access, simply referred to as RDMA) delays up to tens of milliseconds. In addition to low latency and good resource utilization, the above-described alternative embodiments support the type of container instance required for on-demand retrieval, thereby further reducing the cost of parent container creation, due to efficient management of the parent container instance. In summary, in the above alternative embodiment, the CXL hardware effectively supports sharing of the parent container, thereby improving the overall resource utilization of the function computing service.

In this embodiment, there is provided an electronic device including a memory in which a computer program is stored, and a processor configured to run the computer program to perform the method in the above embodiment.

The above-described programs may be run on a processor or may also be stored in memory (or referred to as computer-readable media), including both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technique. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device.

These computer programs may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks, and corresponding steps may be implemented in different modules.

Such an arrangement is provided in this embodiment. The device is called a container creation processing device, and is located in a node, and includes: a reading module, configured to read, from a shared memory, data of a container stored in the shared memory, where the data of the container is written into the shared memory by other nodes in a process of creating the container, the shared memory is shared by a plurality of nodes, and the plurality of nodes include the node and the other nodes; and the creation module is used for creating a new container by using the read data of the container.

The system or the device is used for realizing the functions of the method in the above embodiment, and each module in the system or the device corresponds to each step in the method, which has been described in the method, and will not be described herein.

Optionally, the shared memory is mapped to each node of the plurality of nodes, and the shared memory mapped on each node is located in a fixed memory address space in each node; and/or, the new container runs in the local memory of the node.

Optionally, the reading module is configured to obtain, from a local memory of the node, a memory address space of the shared memory map in the local memory; copying the data of the container from the memory address space to the local memory.

Optionally, the plurality of nodes are connected to a computing fast connect CXL switch and are connected to the shared memory through the CXL interacting machine.

Optionally, the creating module is configured to create the new container by using the read data of the container by the duplicate Fork function.

Optionally, after creating the new container, data common to the container and the new container is saved in the shared space, the apparatus further comprising: the data processing module is used for copying the part needing to be modified in the shared data under the condition that the new container modifies the shared data; and modifying the copied partial data needing modification, and storing the modified data in the shared space.

In another alternative embodiment, there is also provided another container creation processing device including: the second creation module is used for creating a container; and the writing module is used for writing the data of the container into a shared memory in the process of creating the container, wherein the data of the container stored in the shared memory can be read by other nodes, the data of the container is used when the other nodes create new containers after being read, and the shared memory is shared by a plurality of nodes, and the nodes comprise the nodes and the other nodes.

Optionally, the container is used to provide a complete runtime environment for applications or functions configured within the container.

Optionally, the shared memory is mapped to each node of the plurality of nodes, and the shared memory mapped on each node is located in a fixed memory address space in each node.

Optionally, the writing module is configured to obtain, from a local memory of the node, a memory address space of the shared memory map in the local memory; writing the data of the container into the memory address space.

It should be noted that, the node using the shared memory may include all the modules in the two devices.

The problem of service quality reduction caused by longer time for creating the container in the related technology is solved by the alternative implementation mode, so that the creation time of the container is shortened, and the service quality is provided.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.

Claims

1. A method of container creation, comprising:

a first node reads data of a container stored in a shared memory from the shared memory, wherein the data of the container is written into the shared memory by other nodes in the process of creating the container, the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the first node and the other nodes;

The first node creates a new container using the read data of the container.

2. The method of claim 1, wherein the shared memory is mapped onto each of the plurality of nodes, the shared memory mapped onto each node being located in a fixed memory address space in each node; and/or, the new container runs in the local memory of the first node.

3. The method of claim 2, the first node reading the data of the container from the shared memory comprising:

the first node obtains the memory address space of the shared memory mapping in the local memory from the local memory of the first node;

the first node copies the container data from the memory address space to the local memory.

4. The method of claim 1, wherein the plurality of nodes are connected to a computing fast connect CXL switch and are connected to the shared memory through the CXL interacting machine.

5. The method of claim 1, wherein the first node creating a new container using the read data of the container comprises:

The first node uses the read data of the container through a copy Fork function to create the new container.

6. The method of any of claims 1-5, wherein after the first node creates the new container, further comprising:

the data shared by the container and the new container is stored in the shared space, and the first node copies the part needing to be modified in the shared data when the new container modifies the shared data;

the first node modifies the copied part of the data needing modification, and stores the modified data in the shared space.

7. A container creation processing method, comprising:

creating a container by the node;

the node writes the data of the container into a shared memory in the process of creating the container, wherein the data of the container stored in the shared memory can be read by other nodes, the data of the container is used when the other nodes create new containers after being read, and the shared memory is shared by a plurality of nodes, and the plurality of nodes comprise the nodes and the other nodes.

8. The method of claim 7, wherein the shared memory is mapped onto each of the plurality of nodes, the shared memory mapped onto each node being located in a fixed memory address space in each node.

9. The method of claim 8, wherein the node writing the container's data into the shared memory in creating the container comprises:

the node obtains the memory address space of the shared memory mapping in the local memory from the local memory of the node;

the node writes the data of the container into the memory address space.

10. A method according to any one of claims 7 to 9, wherein the plurality of nodes are connected to a computing fast connect CXL switch and are connected to the shared memory via the CXL interacting machine.

11. A container creation system comprising a plurality of nodes sharing use of a shared memory, the plurality of nodes being connected to a computing fast connecting CXL switch and connected to the shared memory through the CXL interacting machine, wherein the plurality of nodes comprises: a node for performing the method of any of claims 7 to 9 and at least one first node for performing the method of any of claims 1 to 6.

12. An electronic device includes a memory and a processor; wherein the memory is for storing one or more computer instructions, wherein the one or more computer instructions are executable by the processor to implement the method steps of any one of claims 1 to 6 or to implement the method steps of any one of claims 7 to 10.

13. A readable storage medium having stored thereon computer instructions, wherein the computer instructions, when executed by a processor, implement the method steps of any of claims 1 to 6 or the method steps of any of claims 7 to 10.