CN116700901A - Container construction and operation system and method based on microkernel - Google Patents

Abstract

The present invention provides a microkernel-based container construction and operation system and method, including: a namespace functional module, a control group functional module, and a fault recovery functional module; wherein, the namespace functional module: used to divide static system resources; Mount point data, network protocol stack data, and process management data are divided, and different application containers are located in different namespaces, accessing different system resources, and realizing the isolation of system resources; control group function module: used to divide dynamic systems Resources, to count and limit CPU resources, memory resources, and I/O bandwidth resources. Different application containers are in different control groups, use limited resources, and realize system resource limitations; fault recovery function module: used to deal with A case where a system service crashes due to a memory error. The present invention can obtain improved performance on the basis of stronger isolation and safety.

Description

Container construction and operation system and method based on microkernel

technical field

The present invention relates to the technical field of virtualization, in particular to a microkernel-based container construction and operation system and method.

Background technique

Containers can provide an isolated environment for the execution of operating systems and applications. In recent years, its application has become more and more common, and the importance of container security has also increased. The isolation of containers is an important part of security. A container design with strong isolation will not affect other containers and operating systems when a container fails. The isolation of containers is the key to supporting the reliability and scalability of containers. However, with the continuous development of the operating system, the traditional container isolation mechanism faces new problems and challenges. For example, the code size of the operating system and software is constantly expanding, resulting in a large number of undiscovered vulnerabilities in the application, which are easily exploited by malicious containers, causing a faulty container to steal other containers running on the same kernel. data, or use resources belonging to other containers for your own use. In response to these problems, researchers in industry and academia have proposed a series of technical solutions to enhance the isolation of containers, including using new software architecture isolation planes to increase isolation, enhancing the isolation of traditional operating systems, and using new hardware to enhance isolation. Isolation, using an operating system with strong isolation, etc.

When running applications in the traditional Linux operating system, because the concept of the process of the operating system is not very isolated, different processes will share resources such as the network, CPU, memory, and disk, and malicious processes can easily Attack the data flow of other processes and steal data from other processes. Processes with high security requirements need additional protection mechanisms to isolate themselves from other processes. Linux provides a namespace (Namespace) and a control group (ControlGroups) mechanism to help processes achieve isolation. The namespace mechanism provides a resource isolation scheme. Each namespace can specify its own process, inter-process communication, network, file and other system resources. These resources are invisible to other namespaces. By putting different processes into different namespaces, resource isolation between processes can be achieved, so that malicious processes cannot directly steal data from other processes. The control group mechanism can limit the amount of network, CPU, memory, disk and other resources used by each process, and can prevent a process from consuming too many system resources and affecting the performance of other processes.

The container is generated on the basis of the namespace mechanism and the control group mechanism, which can provide an isolated execution environment for the process running in the container. LXC is a typical container. LXC is the abbreviation of Linux Container, which is a container natively supported by Linux. LXC regards each namespace as a container, and each container has its own process view, inter-process communication, file system and network view, etc. Due to the use of namespaces for isolation, different containers cannot access data from each other, nor can they affect the control flow executed in other containers. Its architecture is shown in Figure 14. In LXC, each container runs an operating system and corresponding application. In order to prevent a container from taking up too many system resources and then affecting the performance of other containers and the kernel, LXC uses the control group mechanism to limit the upper limit of system resources that can be used by process groups running in each namespace, that is, limit each container The amount of network, CPU, memory, disk and other resources that can be occupied.

Although the container uses the namespace mechanism and the control group mechanism to enhance its own isolation, it still has two isolation problems: security isolation and performance isolation.

Security isolation refers to whether a container can access the data of other containers, or affect the security of other containers. Containers are more secure than ordinary processes, but they still have the problem of security isolation. This is because although the containers are isolated by the namespace mechanism and the control group mechanism, they are still processes running on the same operating system. To work properly, the container must trust the entire operating system and use the code of the operating system as its Trusted Code Base (TCB). The code size of the operating system is rapidly expanding. The code size of the Linux kernel has increased from 150,000 lines of code in version v1.0 to more than 20 million lines in version 4.15. loopholes. If a container triggers a vulnerability in an operating system, it could potentially gain access or attack other containers on that operating system or even the operating system itself. For example, the published shocker attack on the Docker platform exploits a design loophole in the system call related to the file handle, allowing the container to access any file on the operating system, including files of other containers, and the security isolation of the container is compromised. destroy.

Performance isolation refers to whether a container can affect the performance of other containers. In LXC and Docker, a container can occupy all CPU resources by default. If the deployer does not manually set the upper limit of the CPU resources that each container can use, when a program with a high CPU load is running in one container, it will affect the performance of other containers. When the CPU is heavily occupied, the transaction efficiency of the database running in LXC will be reduced by about 10%. In addition, due to the large number of vulnerabilities hidden in the operating system, a container can not only use the vulnerabilities to attack the security of other containers or operating systems, but it can also use the vulnerabilities to make the operating system allocate more resources to itself, encroaching on resources that should belong to other resources. The resources of a container or operating system affect the performance of other containers. The data shows that when the disk I/O resources are fully occupied, the efficiency of the database running in LXC will be reduced by about 15%. It is nearly 30% less efficient when memory resources are full.

It can be seen that although the traditional container has enhanced the isolation of the process, it still has the problem of security isolation and performance isolation, and there is a lot of room for improvement.

Contents of the invention

Aiming at the defects in the prior art, the present invention provides a microkernel-based container construction and operation system and method.

According to a microkernel-based container construction and operation system and method provided by the present invention, the scheme is as follows:

In the first aspect, a microkernel-based container construction and operation system is provided, and the system includes: a namespace function module, a control group function module, and a failure recovery function module;

Among them, the namespace function module: used to divide static system resources; divide mount point data, network protocol stack data, process management data, different application containers are located in different namespaces, access different system resources, and realize Isolation of system resources;

Control group function module: used to divide dynamic system resources, collect statistics and limit CPU resources, memory resources and I/O bandwidth resources, different application containers are in different control groups, use limited resources, and realize system resource allocation limit;

Fault recovery function module: used to deal with the crash of system services caused by memory errors;

The system also includes a system container, which strengthens the resource statistics and fault recovery of the system service process.

Preferably, the namespace function module includes: creation, addition, exit, destruction and use of the file system mount point namespace;

Among them, the steps to create a file system mount point namespace are as follows:

Step 1): The creation request is initiated, and the container management program sends a request to the system container through inter-process communication to create a namespace of the file system mount point;

Step 2): Obtain the working path sent by the container management program, and determine whether the length of the path is less than 255 characters;

Step 3): Obtain the mount point information of the working path in the original state, and obtain the mount point information from the mount point information in the original state according to the working path;

Step 4): Send a request to create a namespace to the corresponding file system, the specific process is introduced in the file system namespace creation;

Step 5): Create a new mount point information linked list;

Step 6): Initialize a new mount point information linked list, and add the mount point information obtained in step 3) to the linked list as the mount point information of the path;

Step 7): Obtain the available namespace IDs from the array;

Step 8): Add the new mount point information linked list to the array element of the system container;

Step 9): The inter-process communication returns, and the creation of a new namespace is completed.

Preferably, the steps of adding the file system mount point namespace are as follows:

Step 1): Initiate a request to join the namespace, and the container management program needs to pass the ID of the mount point system container namespace and the system service type into the kernel;

Step 2): Obtain the mount point system container namespace ID and system service type passed in by the container management program;

Step 3): Fill in the mount point system container namespace ID passed in by the container management program into the position of the mount point system container namespace of the application container process;

Step 4): Complete the request to join the namespace, and return to the user state from the kernel state.

Preferably, the steps for exiting the file system mount point namespace are as follows:

Step 1): Initiate a request to exit the namespace, and the container management program needs to pass the system service type of the mount point system container into the kernel;

Step 2): Obtain the system service type imported by the container management program, that is, the mount point system container system service type;

Step 3): Clear the namespace data corresponding to the mount point system container in the kernel;

Step 4): Complete the namespace exit request, and return to the user state from the kernel state.

Preferably, the steps for destroying the file system mount point namespace are as follows:

Step 1): A destruction request is initiated, and the container management program sends a request to the system container through inter-process communication to destroy the namespace of the file system mount point;

Step 2): Obtain the namespace ID sent by the container management program;

Step 3): Determine whether the namespace ID is 0, if it is 0, it represents the root namespace and cannot be destroyed;

Step 4): Determine whether the namespace corresponding to the namespace ID exists, and if it does not exist, it cannot be destroyed;

Step 5): Obtain the mount point information of the path;

Step 6): Send a request to the corresponding file system to destroy the namespace;

Step 7): Clear the current mount point information linked list, including releasing memory and assigning the pointer to 0;

Step 8): Empty the corresponding namespace elements in the array of the system container;

Step 9): The inter-process communication request is returned, and the destruction of the namespace is completed.

Preferably, the steps to use the file system mount point namespace are as follows:

Step 1): The application container initiates a request and sends an inter-process communication request to the mount point system service;

Step 2): Obtain the namespace ID of the current application container in the kernel state;

Step 3): Obtain the corresponding system container from the structure related to the inter-process communication request;

Step 4): switch the process to the system container process, and pass the namespace ID;

Step 5): Obtain the namespace ID passed by the kernel;

Step 6): According to the namespace ID, find the mount point linked list information of the corresponding namespace from the array and switch;

Step 7): Execute a specific application container request;

Step 8): After the request is processed, return to the kernel state;

Step 9): Complete the request and return to the application container.

Preferably, the control group functional modules include:

Statistics and limitation of CPU resources: The total number of clock interrupts received by the process is used as the CPU resource usage; when the clock interrupt is triggered, the kernel obtains the process running on the CPU that currently triggers the clock interrupt, and counts the number of clock interrupts received by the process Perform plus 1 operation;

Modify the scheduling strategy. After the time slice of the current process is 0, enter the scheduling strategy, take out a process from the waiting queue, and calculate the CPU usage, that is, the number of clock interrupts received by the process and the clocks received by all processes in the waiting queue. The ratio of the total number of interrupts, comparing the actual CPU usage with the CPU usage set by the user;

If the CPU usage of the process is high, reduce the time slice, or even let the process wait for a long time; if the CPU usage of the process is low, increase the time slice;

Through the modified scheduling strategy, the time slice of each process is controlled separately, and when each process is scheduled for a complete round, it is ensured that the CPU usage of each process meets the value set by the user;

Statistics and limitation of memory resources: Capture the exceptions that occur in page fault exceptions, and add the allocated physical page size to the corresponding application container process and application container, and count the usage of memory resources of physical pages;

If it is found that the physical memory usage of the application container exceeds the value set by the user during this process, it is necessary to kill the application container process that exceeds the memory usage or suspend the operation of the application container process;

Count and limit I/O bandwidth resources: By adding a current limiter system service between the file system system service and the device driver system service, each I/O request will be captured by the current limiter system service and processed according to The type and size of the I/O request determine whether the request is met. If not, the request is suspended. If it is satisfied, the request is issued and the number of tokens in the current limiter system service is updated. ;

The number of tokens increases gradually with the operation of the system, and there is an upper limit on the number of tokens. Once the upper limit is reached, the number of tokens cannot continue to increase.

Preferably, the fault recovery function module includes: when a fault error occurs, capture the fault. The most common fault is a page fault exception. After the capture is completed, exit the abnormal system container process and reclaim all resources ;

Then send a message to the process management system container to restart the system container. After receiving the message, the process management system container restarts the system container immediately, and rebuilds the internal content of the system container and inter-process communication.

Preferably, the system service process in the user mode of the system container is also managed as a container, and the CPU and memory overhead of the system service process are counted, and the system service process is uniformly managed;

The system accelerates the I/O speed of the microkernel through direct memory access, uses capability to manage the data that needs to be transferred, and directly copies the data from the device to the memory or directly writes the data from the memory to the device through direct memory access, thereby reducing the number of processes The amount of inter-communication and the number of repeated memory copies.

In a second aspect, a microkernel-based container construction and operation method is provided, the method comprising:

Namespace function steps: Divide static system resources; divide mount point data, network protocol stack data, and process management data. Different application containers are located in different namespaces, access different system resources, and realize system resource isolation. ;

Control group function steps: divide dynamic system resources, collect statistics and limit CPU resources, memory resources, and I/O bandwidth resources, place different application containers in different control groups, use limited resources, and realize system resource limitations;

Fault recovery function steps: handle the crash of system services caused by memory errors.

Compared with the prior art, the present invention has the following beneficial effects:

1. The present invention proposes the concept of a system container. The system container represents that not only programs run by users will be included in the container, and all system services will run in the container, which can ensure more accurate statistics on the use of system resources;

2. The present invention uses direct memory access to improve the performance of the microkernel, skipping repeated memory copying and inter-process communication;

3. The present invention can provide flexible container support in a microkernel environment, and can be flexibly transplanted to various microkernel platforms without the need for specific macrokernel environment support, and can further support specific containers through flexible interrupt isolation and scheduling algorithm independence. The real-time requirements in the container, the system container used can make resource statistics more accurate, and manage the behavior of system services separately to achieve stronger resource isolation capabilities;

4. Compared with the prior art, the present invention can also obtain improved performance on the basis of stronger isolation and safety.

Other beneficial effects of the present invention will be set forth through the introduction of specific technical features and technical solutions in the specific embodiments, and those skilled in the art should be able to understand the implications of the technical features and technical solutions through the introduction of these technical features and technical solutions. beneficial technical effects.

Description of drawings

Other characteristics, objects and advantages of the present invention will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

Fig. 1 is a structure diagram of the present invention;

Fig. 2 is a schematic diagram of the namespace design framework in the present invention;

FIG. 3 is a schematic diagram of the creation process of the file system mount point namespace in the present invention;

FIG. 4 is a schematic diagram of the adding process of the file system mount point namespace in the present invention;

5 is a schematic diagram of the exit process of the file system mount point namespace in the present invention;

FIG. 6 is a schematic diagram of the destruction process of the file system mount point namespace in the present invention;

FIG. 7 is a schematic diagram of the use flow of the file system mount point namespace in the present invention;

Fig. 8 is a schematic diagram of the control group design architecture in the present invention;

Fig. 9 is a schematic diagram of the processing flow of fault recovery in the present invention;

Fig. 10 is a schematic flow chart of direct memory access I/O in the present invention;

Figure 11 shows CPU resource statistics;

Figure 12 is the processing flow of the memory control group;

Fig. 13 is the processing flow of the I/O control group;

Figure 14 shows the LXC architecture.

Detailed ways

The present invention will be described in detail below in conjunction with specific embodiments. The following examples will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

The embodiment of the present invention provides a microkernel-based container construction and operation system. Referring to FIG. 1 , the system includes a namespace function module, a control group function module, and a fault recovery function module.

The invention also innovatively proposes a system container to strengthen the resource statistics and fault recovery of the system service process, and proposes a method of direct memory access to accelerate microkernel I/O.

1. Namespace function module: as shown in Figure 2, it is used to divide static system resources; divide mount point data, network protocol stack data, and process management data. Different application containers are located in different namespaces. Access Different system resources realize the isolation of system resources.

The usage of the namespace mainly includes creating, joining, exiting, destroying and using.

The creation of the namespace is completed in the user state, including obtaining user requests, creating and initializing system resources, and so on. Different namespaces perform different system resource creation and initialization processes.

For the file system mount point namespace, it is necessary to obtain the work path passed in by the user, create and initialize the mount point information list, and so on.

For the LwIP network protocol stack namespace, a new continuous array needs to be created to store network data, and a new linked list needs to be created to store network interfaces.

For the process management namespace, it is necessary to select the process node in the process tree as the new root node and as the root node for access.

The addition of the namespace is completed in the kernel state, and the container management program will pass the corresponding namespace ID and the type of the corresponding system container into the kernel state, and fill in the data in the corresponding position in the kernel state, that is, the addition of the namespace is completed.

The exit of the namespace is completed in the kernel state. The container management program transfers the corresponding system container type into the kernel state, and deletes the data at the corresponding location in the kernel state, that is, the exit of the namespace is completed.

The destruction of the namespace is completed in the user mode, and the system resources created when the namespace is created need to be destroyed.

The use of namespaces depends on inter-process communication. When inter-process communication needs to be sent, the ID of the corresponding namespace is obtained in the kernel mode, and then the ID is passed to the upper-layer system container, and the system container selects the corresponding system resources to use.

Specifically, referring to Figure 3, the steps for creating a file system mount point namespace are as follows:

Step 1): The creation request is initiated, and the container management program sends a request to the system container through inter-process communication to create a namespace of the file system mount point;

Step 2): Obtain the working path sent by the container management program, and determine whether the length of the path is less than 255 characters;

Step 3): Obtain the mount point information of the working path in the original state, and obtain the mount point information from the mount point information in the original state according to the working path;

Step 4): Send a request to create a namespace to the corresponding file system, the specific process is introduced in the file system namespace creation;

Step 5): Create a new mount point information linked list;

Step 6): Initialize a new mount point information linked list, and add the mount point information obtained in step 3) to the linked list as the mount point information of the path;

Step 7): Obtain the available namespace IDs from the array;

Step 8): Add the new mount point information linked list to the array element of the system container;

Step 9): The inter-process communication returns, and the creation of a new namespace is completed.

Referring to Figure 4, the steps to add a file system mount point namespace are as follows:

Step 1): Initiate a request to join the namespace, and the container management program needs to pass the ID of the mount point system container namespace and the system service type into the kernel;

Step 2): Obtain the mount point system container namespace ID and system service type passed in by the container management program;

Step 3): Fill in the mount point system container namespace ID passed in by the container management program into the position of the mount point system container namespace of the application container process;

Step 4): Complete the request to join the namespace, and return to the user state from the kernel state.

Referring to Figure 5, the steps to exit the file system mount point namespace are as follows:

Step 1): Initiate a request to exit the namespace, and the container management program needs to pass the system service type of the mount point system container into the kernel;

Step 2): Obtain the system service type imported by the container management program, that is, the mount point system container system service type;

Step 3): Clear the namespace data corresponding to the mount point system container in the kernel;

Step 4): Complete the namespace exit request, and return to the user state from the kernel state.

Referring to Figure 6, the steps to destroy the file system mount point namespace are as follows:

Step 1): A destruction request is initiated, and the container management program sends a request to the system container through inter-process communication to destroy the namespace of the file system mount point;

Step 2): Obtain the namespace ID sent by the container management program;

Step 3): Determine whether the namespace ID is 0, if it is 0, it represents the root namespace and cannot be destroyed;

Step 4): Determine whether the namespace corresponding to the namespace ID exists, and if it does not exist, it cannot be destroyed;

Step 5): Obtain the mount point information of the "/" path;

Step 6): Send a request to the corresponding file system to destroy the namespace, and the specific process will be introduced in Destroying the Namespace of the File System;

Step 7): Clear the current mount point information linked list, including releasing memory and assigning the pointer to 0;

Step 8): Empty the corresponding namespace elements in the array of the system container;

Step 9): The inter-process communication request is returned, and the destruction of the namespace is completed.

Referring to Figure 7, the steps to use the file system mount point namespace are as follows:

Step 1): The application container initiates a request and sends an inter-process communication request to the mount point system service;

Step 2): Obtain the namespace ID of the current application container in the kernel state, because the process of adding the namespace has already written the ID of the corresponding namespace in the corresponding position;

Step 3): Obtain the corresponding system container from the structure related to the inter-process communication request;

Step 4): switch the process to the system container process, and pass the namespace ID;

Step 5): Obtain the namespace ID passed by the kernel;

Step 6): According to the namespace ID, find the mount point linked list information of the corresponding namespace from the array and switch;

Step 7): Execute a specific application container request;

Step 8): After the request is processed, return to the kernel state;

Step 9): Complete the request and return to the application container.

2. Control group function module: as shown in Figure 8, it is used to divide dynamic system resources, and can count and limit CPU resources, memory resources and I/O bandwidth resources. Different application containers are in different control groups. Use certain limited resources to realize the limitation of system resources.

The use of control groups mainly includes resource statistics and resource limits.

The methods of counting and limiting CPU resources are as follows:

The CPU resource statistics method is to use the total number of clock interrupts received by the process as the CPU resource usage. Because the clock interrupt is triggered at a fixed time interval, when the clock interrupt is triggered, the kernel can obtain the process running on the CPU that currently triggers the clock interrupt, and add 1 to the number of clock interrupts received by the process.

In order to control the CPU utilization of the process, in addition to the statistics of the CPU resources mentioned above, it is also necessary to modify the scheduling policy.

After the time slice of the current process is 0, enter the scheduling strategy. Take a process out of the waiting queue and calculate its CPU usage, that is, the ratio of the number of clock interruptions received by the process to the sum of the number of clock interruptions received by all processes in the waiting queue, and compare the actual CPU usage with the user-set CPU usage for comparison.

If the CPU usage of the process is high, the time slice will be reduced, and even the process will be in a waiting state for a long time; if the CPU usage of the process is low, the time slice will be increased.

Through the above modified scheduling strategy, the time slice of each process can be individually controlled. When each process is scheduled for a complete round, it can ensure that the CPU usage of each process meets the value set by the user.

The methods of counting and limiting memory resources are as follows:

Capture the exception that occurs when the page fault exception occurs, and add the allocated physical page size to the corresponding application container process and application container, so as to count the usage of memory resources of the physical page.

If it is found that the physical memory usage of the application container exceeds the value set by the user during this process, it is necessary to kill the application container process exceeding the memory usage or suspend the operation of the application container process.

The resource statistics method of the memory control group is to make statistics when the kernel allocates physical memory pages. Statistical physical memory data in the functions get_pages and free_pages, and add the data to the currently running process.

In order to limit the physical memory used by the application container, it is necessary to make a judgment every time the physical memory is counted. The judgment of the memory statistics is based on the process group. After the memory data of each application container process is processed, the corresponding data will be updated. Go to the process group, and judge whether the memory of the process group exceeds the user's preset value.

If the actual physical memory usage of the process group exceeds the user's preset value, there are the following two options.

1. Kill the process in the process group that exceeds the memory directly, and release the memory of the process;

2. The process remains in the waiting state until the processes in the process group release enough memory to allow waiting;

The methods of counting and limiting I/O bandwidth resources are as follows:

The I/O control group uses the current limiter to limit the I/O bandwidth, intercepts and parses all I/O requests sent to the device driver system container to obtain the corresponding request and size, and counts them. The logic of the current limiter to control the bandwidth is mainly realized by the token bucket algorithm. The principle of the token bucket algorithm is to maintain a token bucket, the system generates tokens at a constant rate, and the token bucket has a rated capacity. When the token bucket is full, newly generated tokens cannot continue to be added to the token bucket.

When a request arrives, it will analyze the type and size of the request, select the token bucket according to the type, check whether the number of tokens in it is enough, if enough, send the request, if not, block the request until there are enough number of tokens.

Through the token bucket algorithm, the number of reads and writes and the number of bytes read and written within a period of time can be limited.

In order to generate tokens at a constant rate, a timer is also maintained in the current limiter, which runs once per second to generate a certain amount of tokens, and also checks whether there are blocked I/O requests that have met the delivery requirements .

The blocking of I/O requests is implemented by the notification mechanism. When it is found that the number of tokens is insufficient, a notification capability will be created and enter the blocking state, and the I/O request and notification capability will be added to the queue, which will be checked in the timer to see if there is I/O that meets the requirements If the request is satisfied, the blocked I/O request will be woken up to complete the sending process.

3. Fault recovery function module: as shown in Figure 9, it is used to deal with the crash of system services caused by memory errors;

When a fault error occurs, the fault can be captured. The most common fault is a page fault exception. After the capture is completed, the system container process that has the exception can be exited and all resources can be recovered.

Then send a message to the process management system container to restart the system container. After receiving the message, the process management system container will immediately restart the system container and rebuild the internal content of the system container and inter-process communication.

Specifically, the fault recovery function is mainly divided into two parts: fault capture and fault recovery. When the application container normally uses the function of the system container, the system container will record the operation of the application container and store it in a memory area of the kernel.

When an error occurs and a page fault occurs, the error will be passed to the kernel, and then it will be judged in the kernel whether there is an error in the system container. If so, all inter-process communication and lock resources in the system container will be recovered, and the system container will exit , all ongoing interprocess communication inside the system container will receive a retry return code.

Then send information to the process management system container. After the process management system container gets the message, it will try to restart the system container, and rebuild the internal content of the system container according to the previously recorded operations, and rebuild the inter-process communication. When the reconstruction is completed, you can It is continued to be used.

In order to more accurately count the resource usage of the system container and perform fault recovery on the system service process, the present invention includes all system service processes in the container, and by this method, the resources of the system service process can also be counted and If the limit is exceeded, the failure recovery function can be triggered to restart and restore the system container.

4. System container: manage the system service process in the user state as a container, which can more accurately count the CPU and memory overhead of the system service process, and uniformly manage the system service process.

5. Direct memory access: As shown in Figure 10, the I/O speed of the microkernel is accelerated through direct memory access. The specific method of implementation is to use capability to manage the data that needs to be transferred, and directly transfer the data from the device through direct memory access. Copy to memory or write directly from memory to device to reduce the amount of inter-process communication and the number of repeated memory copies.

The present invention also provides a microkernel-based container construction and operation method, the microkernel-based container construction and operation system can be realized by executing the process steps of the microkernel-based container construction and operation method, which is the technical field A skilled person may understand the microkernel-based container construction and operation method as a preferred implementation manner of the microkernel-based container construction and operation system. The method includes:

Namespace function steps: Divide static system resources; divide mount point data, network protocol stack data, and process management data. Different application containers are located in different namespaces, access different system resources, and realize system resource isolation. ;

Control group function steps: divide dynamic system resources, collect statistics and limit CPU resources, memory resources, and I/O bandwidth resources, place different application containers in different control groups, use limited resources, and realize system resource limitations;

Fault recovery function steps: handle the crash of system services caused by memory errors.

Next, the present invention will be described more specifically.

A microkernel-based container construction and operation system adopts microkernel architecture and divides namespace function design, control group function design and fault recovery function design.

First of all, in terms of namespace function design, as shown in Figure 2, the namespace function of the microkernel container in this solution is mainly at the EL0 layer, and part of the implementation code is also arranged on the EL1 layer.

For the application container just started, add the capability of the corresponding namespace to it, and initialize the value to 0, 0 means that it uses the default initialization system resources in the corresponding system container.

When the user sends inter-process communication to obtain the service of the system container, it will first obtain the capability of the namespace corresponding to the system container from the kernel, and carry the namespace information to the system container in the user mode to select different system resources.

For different system containers in the microkernel, different system resource division methods need to be designed.

For the file system mount point system container, the function of its system container is to select a different mount point according to the path provided by the user process, and return the corresponding ID and the capability of inter-process communication, and the application container according to the corresponding ID and capability Send specific file operations to the corresponding file system system container, and also provide mount and umount operations.

In the system container, the mount point information in the system is mainly stored, so the information should be isolated. A linked list is used in the system container to maintain a set of mount point information. In order to name the new file system mount point Spaces have different mount point information, so each time a new file system mount point namespace is created, a new mount point information list needs to be created to store the mount points in the new file system mount point namespace. Mount point information, and the application container will select the corresponding mount point information list according to the mount point namespace of the file system.

For the LwIP network protocol stack system container, the function of its system container is to provide network support for upper-layer applications, and perform network protocol stack operations such as open, close, read, and write according to user requests.

In the system container, the main information stored is the list of network interfaces and network data. The network interface list is a series of network interfaces organized through a linked list; the network data is a continuous array of memory, which is used to store the data sent and received in the network interface.

In the LwIP network protocol stack system container, every time a new network protocol stack namespace is created, an empty linked list needs to be created to store the network interfaces in the new network protocol stack namespace and initialize a loopback network for it interface, and create a new memory-contiguous array that handles network data in the new network stack namespace.

For the process management system container, the function of its system container is to provide process ID and process tree support, and is responsible for operations such as creating new processes and recycling zombie processes.

The main information stored in the system container is the first process created when the system starts, that is, the root node of the process tree.

In the process management system container, every time a new process management system container is created, a node in the process tree needs to be selected as the new process tree root node. Any process created in the process management namespace will be generated downward according to the tree structure , will not be observed by other process management namespaces.

Control group function design mainly includes CPU, memory and I/O bandwidth.

The CPU control group is implemented at the EL1 layer. For the application container of the microkernel, in order to meet the real-time requirements and add the function of the CPU control group, the priority-based time slice round-robin scheduling algorithm is used to support the application container in real time. .

The priority-based time slice round-robin scheduling algorithm achieves real-time performance by specifying the priority of the process. Different processes have different priorities. When scheduling, select the specific process that needs to be scheduled according to the priority of the process.

If the priority of the process is higher, the process with higher priority will be prioritized during scheduling.

If the priorities of the processes are the same, time slice round-robin scheduling will be used to schedule the processes with the same priorities.

The CPU control group cannot be used for processes of different priorities, because there will be process preemption, and the CPU usage cannot be accurately counted. However, for processes of the same priority, the CPU control group can be used. Among processes with the same priority , will count the CPU usage of the process during scheduling, and use the CPU control group to control it.

Referring to FIG. 11 , the CPU resource statistics method is to use the clock interrupt received by the process as the CPU resource usage. Because the clock interrupt is triggered at a fixed time interval, when the clock interrupt is triggered, the kernel can obtain the process running on the CPU that currently triggers the clock interrupt, and add 1 to the number of clock interrupts received by the process.

Because of the existence of inter-process communication under the microkernel architecture, it is necessary to consider the situation that the process subject changes due to inter-communication behavior for short. Inter-process communication will cause the execution right of the process to switch. When the process of the application container applies for services from the system container through inter-process communication, it is no longer the original process, but switched to the process of the system container, but this part of the operation Time still belongs to the process of the application container.

In order to solve this problem, we pay attention to the invariant in the inter-process communication process of the application container process, which is the scheduling context. The inter-process communication will pass the execution body of the application container process to the system container process, so we will count Variables for CPU resources are stored in the executable. Even if the process of the application container is switched to the system container process through inter-process communication, the execution time of the application container process can still be counted correctly.

In order to control the CPU usage of the process, in addition to the CPU resource statistics mentioned above, the scheduling policy needs to be modified to adjust the CPU usage of the process by adjusting the time slice (Time Budget) of the process.

After the time slice of the current process is 0, enter the scheduling policy. Take out a process from the waiting queue, calculate the CPU usage of the process, that is, the ratio of the number of clock interruptions received by the process to the sum of the number of clock interruptions received by all processes in the waiting queue, and compare the actual CPU usage with the user setting CPU usage for comparison.

If the CPU usage of the process is high, the time slice will be reduced, and even the process will be in a waiting state for a long time; if the CPU usage of the process is low, the time slice will be increased.

Through the above scheduling strategy, the time slice of each process can be individually controlled. When each process is scheduled for a complete round, the CPU usage of each process will meet the user's set value.

The memory control group is also implemented at the EL1 layer. The memory control group limits the physical memory usage of the application container, including all anonymous memory pages that have established page table mapping; for shared memory, this part of the physical memory usage is given to The process that is using this memory page for the first time.

Referring to Figure 12, the processing flow of the memory control group.

Similarly, inter-process communication needs to be considered, so the same method is used here to count the corresponding data in the execution body of the process. After the inter-process communication occurs, the used physical memory pages can still be counted correctly. in the application container.

I/O bandwidth resources are counted above the driver layer. Under the microkernel architecture, the calling process of block device I/O is application container -> file system system container -> driver system container. In order to be able to count all block device I/O requests, a new system container is added between the file system system container and the drive system container, called a current limiter, to control the I/O bandwidth. All data in and out goes through the throttle.

Referring to Figure 13, it is the processing flow of the I/O control group.

The logic of controlling the I/O bandwidth of the current limiter mainly relies on the token bucket algorithm. The principle of the token bucket algorithm is to maintain a token bucket, the system continuously generates tokens at a constant rate, and the token bucket has an upper limit capacity. When the token bucket is full, newly generated tokens cannot continue to be added to the token bucket.

When an I/O request arrives, it will analyze the type and size of the I/O request, choose to read the token bucket or write the token bucket according to the type, check whether the number of tokens in the token bucket is sufficient, and if so, then Subtract the specified number of tokens and issue the request; if not enough, block the request and wait for the system to have a sufficient number of token buckets.

Through the token bucket algorithm, the I/O read and write frequency bandwidth and the I/O read and write bandwidth can be limited.

In order to continuously generate tokens at a constant rate, a timer is maintained in the current limiter, which runs once every second to generate a certain amount of tokens, and also checks whether there are blocked I/O requests that have met the delivery requirements .

The blocking and waking up of I/O requests adopt the notification mechanism. When it is found that the number of tokens is insufficient, a notification capability will be created and enter the blocking state, and the I/O request and notification capability will be added to the queue, which will be checked in the timer to see if there is an I/O request that meets the requirements. If the O request is satisfied, it will wake up the blocked I/O request and complete the I/O request delivery process.

For the strong reliability of the system, we have designed a fault recovery function for internal errors in the system container, which can ensure that when the system container crashes due to an internal error, the crash error can be captured, and the system container can be restarted to restore the key data in it, ensuring that the application Container requests can be re-executed.

Referring to FIG. 9, it is a processing flow of fault recovery.

When an error occurs in the system container process that causes a page fault exception, the system can capture the error at the page fault and analyze whether the error comes from the system container process. If the error comes from the system container process, it means that the logic inside the system container process or A memory error has occurred and needs to be restarted.

First of all, because it is a page fault exception, all inter-process communication data managed by the current system container process can be obtained through the system container process data, and all inter-process communication locks are released, and the return value of the application container process is set. The inter-process communication connection is unavailable, and finally the system container process exits. When the system container exits, it will send a message to the process management system container. After receiving the information, the process management system container will try to restart the system container and restore internal data.

In the past, containers were user-mode applications wrapped in the container, but in the microkernel scenario, the system services originally in the kernel mode were moved up to the user mode, so the system service process can also be included in the container. All resources in the system are handed over to the container management. In this way, the resources of the system service process can be counted in a more fine-grained manner. Combined with the fault recovery capability mentioned in 1, when the system container has an error, it can be captured And restarting will not affect the normal operation of the system.

The management scope of the system container is also different from that of the application container. The management scope of the application container is the namespace and control group; while the management scope of the system container is the control group and fault recovery.

Application containers need to manage the system resources they can access and limit the total amount of resources that application containers can access, so namespaces are used to manage the system resources they can access, and control groups are used to limit the total amount of resources that application containers can access.

The failure of the application container is caused by the code written by the user, so the system is not responsible for fault recovery for the user's error, while the failure of the system container needs to be taken care of by the system, and for better performance isolation, in order to ensure The CPU and memory usage of the system container will not exceed the specified limit, so the system container will collect statistics on the CPU and memory usage of the system container. If the CPU and memory resource usage exceeds the rated limit, a fault recovery will be triggered and the The system container is restarted and restored to ensure that the application container can be served normally.

The present invention innovatively proposes to use direct memory access to accelerate the I/O speed of the microkernel. For common microkernels, because different system containers are in different address spaces, and the address spaces are used as shared memory The amount of memory for inter-process communication is limited, so it is necessary to divide a request into multiple requests, and complete a complete request through continuous memory copying and a large amount of inter-process communication.

There is such a situation that the user wants to read a file size of 1MB, but the shared memory is only 4KB, so the user needs to divide a request into multiple requests, and the request is in the process from the file system to the driver, because there are other metadata required Portable, so the amount of memory that can actually be used to store file content will become smaller and smaller, which will also lead to a thousand inter-process communications from the user to the file system, and the number of inter-process communications from the file system to the driver It will be as high as two thousand, and this situation will be exacerbated with the extension of the inter-process communication chain, resulting in an exponential increase in the number of inter-process communication throughout the request.

In order to solve the above two problems, the present invention proposes a solution for accelerating the I/O of the microkernel by using direct memory access. Referring to FIG. 10 , it is a flow of direct memory access operation I/O.

When the application container sends a request, if it is a read request, the application container will apply for a memory space of a specified size in advance, and pass the memory space of the specified size as a capability to the file system system container and device driver system container, and the device driver system container After obtaining this capability, first check whether the physical address corresponding to the capability has been mapped. If there is no mapped memory, first map the physical memory, and then directly perform direct memory access operations on the physical memory contained in the capability, and transfer data from the device to Directly write to the corresponding physical memory space, because this part is asynchronous, so the inter-process communication of the application container can return directly, and does not need to carry any data back, there is no memory copy and redundant inter-process communication operations.

If it is a write request, the application container will use the physical memory space corresponding to the data to be written as a capability, and send this capability and other request data to the file system system container and device driver system container, and the device driver system container After getting this capability, you can directly write data from the memory to the designated location of the driver through direct memory access, and return after the execution request is issued.

When a read or write request is complete, an interrupt is triggered, telling the system that the current request has been completed.

The embodiment of the present invention provides a microkernel-based container construction and operation system and method, which can provide flexible container support in a microkernel environment, and can be flexibly transplanted to various microkernel platforms without requiring specific macrokernel environment support , the present invention can further support real-time requirements in a specific container through flexible interrupt isolation and scheduling algorithm independence. The system container used in the present invention can make resource statistics more accurate, and perform separate management on the behavior of system services to achieve Stronger resource isolation capabilities. Compared with the prior art, on the basis of obtaining stronger isolation and safety, the present invention can also obtain performance improvement.

Those skilled in the art know that, in addition to realizing the system provided by the present invention and its various devices, modules, and units in a purely computer-readable program code mode, the system provided by the present invention and its various devices can be completely programmed by logically programming the method steps. , modules, and units implement the same functions in the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by the present invention can be regarded as a hardware component, and the devices, modules, and units included in it for realizing various functions can also be regarded as hardware components. The structure; the devices, modules, and units for realizing various functions can also be regarded as not only the software modules for realizing the method, but also the structures in the hardware components.

Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art may make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. In the case of no conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims (10)

1. A microkernel-based container build and run system, comprising: a namespace function module, a control group function module, and a fault recovery function module;

wherein the namespace function module: for partitioning static system resources; dividing mounting point data, network protocol stack data and process management data, accessing different system resources by different namespaces where different application containers are located, and realizing isolation of the system resources;

control group function module: the system resource control method is used for dividing dynamic system resources, counting and limiting CPU resources, memory resources and I/O bandwidth resources, using limited resources in different control groups where different application containers are located, and realizing the limitation of the system resources;

fault recovery function module: the method is used for processing the condition of system service breakdown caused by memory errors;

the system also includes a system container to enhance resource statistics and failure recovery for the system service processes.

2. The microkernel-based container build and run system of claim 1, wherein the namespace function module comprises: creating, joining, exiting, destroying and using a file system mounting point name space;

The file system mount point namespaces are created as follows:

step 1): initiating a creation request, sending a request to a system container by a container management program in an inter-process communication mode, and creating a naming space of a file system mounting point;

step 2): acquiring a working path sent by a container management program, and judging whether the path length is smaller than 255 characters;

step 3): acquiring mounting point information of a working path in an original state, and acquiring mounting point information from the mounting point information in the original state according to the working path;

step 4): sending a request for creating a namespace to a corresponding file system, wherein a specific flow is introduced in the creation of the namespace of the file system;

step 5): creating a new mounting point information linked list;

step 6): initializing a new mounting point information linked list, and adding the mounting point information acquired in the step 3) into the linked list as mounting point information of a path;

step 7): acquiring available namespaces ID from the array;

step 8): adding a new mounting point information linked list into an array element of a system container;

step 9): the inter-process communication returns to complete the creation of the new namespace.

3. The microkernel-based container build and run system of claim 2 wherein the step of joining a file system mount point namespace is as follows:

Step 1): initiating a request for joining a name space, wherein a container management program needs to transmit an ID of a name space of a system container of a mounting point and a system service type into a kernel;

step 2): acquiring a system container name space ID and a system service type of a mounting point system, which are transmitted by a container management program;

step 3): filling the name space ID of the mount point system container, which is transmitted by the container management program, into the position of the name space of the mount point system container of the application container process;

step 4): and finishing the namespace joining request, and returning to the user mode from the kernel mode.

4. The microkernel-based container build and run system of claim 1 wherein the step of exiting the file system mount point namespace is as follows:

step 1): initiating a request for exiting a namespace, wherein a container management program needs to transmit the system service type of the system container of the mounting point into a kernel;

step 2): acquiring a system service type transmitted by a container management program, namely a system service type of a system container of a mounting point system;

step 3): clearing up the namespaces corresponding to the system containers of the mounting points in the kernel;

step 4): and finishing the namespace exit request, and returning to the user mode from the kernel mode.

5. The microkernel-based container build and run system as in claim 1 wherein the step of destroying the file system mount point namespaces is as follows:

step 1): the method comprises the steps that a destruction request is initiated, a container management program sends a request to a system container in an inter-process communication mode, and a naming space of a file system mounting point is destroyed;

step 2): acquiring a name space ID sent by a container management program;

step 3): judging whether the name space ID is 0, if so, representing a root name space, and failing to destroy;

step 4): judging whether a name space corresponding to the name space ID exists or not, and if the name space exists, failing to destroy the name space;

step 5): acquiring mounting point information of a path;

step 6): sending a request for destroying the name space to a corresponding file system;

step 7): clearing a current mounting point information linked list, wherein the current mounting point information linked list comprises a memory release and an assignment pointer of 0;

step 8): clearing corresponding name space elements in the array of the system container;

step 9): and returning the inter-process communication request to complete the destruction of the naming space.

6. The microkernel-based container build and run system as in claim 1 wherein the step of using the file system mount point namespace is as follows:

Step 1): the application container initiates a request and sends an inter-process communication request to the mounting point system service;

step 2): acquiring a name space ID of a current application container in a kernel mode;

step 3): acquiring a corresponding system container from a structure body related to the inter-process communication request;

step 4): switching the process to a system container process and transmitting a namespace ID;

step 5): acquiring a name space ID transferred by a kernel;

step 6): searching the mounting point linked list information of the corresponding name space from the array according to the name space ID and switching;

step 7): executing a specific application container request;

step 8): after the request is processed, returning to a kernel mode;

step 9): and finishing the request and returning to the application container.

7. The microkernel-based container build and run system of claim 1, wherein the control group function module comprises:

statistics and limitation of CPU resources: taking the total number of clock interruption received by a process as the CPU resource usage amount; when the clock interrupt is triggered, a process running on a CPU (central processing unit) which triggers the clock interrupt at present is acquired by a kernel, and the number of the clock interrupts received by the process is added with 1;

modifying the scheduling strategy, entering the scheduling strategy after the time slice of the current process is 0, taking out a process from the waiting queue, calculating the CPU utilization rate, namely the ratio of the number of clock interrupts received by the process to the sum of the number of clock interrupts received by all processes in the waiting queue, and comparing the actual CPU utilization rate with the CPU utilization rate set by a user;

If the CPU utilization rate of the process is higher, the time slice is reduced, and even the process is in a waiting state for a long time; if the CPU utilization rate of the process is lower, the time slice is enlarged;

independently controlling the time slices of each process through a modified scheduling strategy, and ensuring that the CPU utilization rate of each process accords with a value set by a user when each process completely schedules one round;

counting and limiting memory resources: capturing the abnormal occurrence of the page fault abnormality, adding the size of the allocated physical page into the corresponding application container process and application container, and counting the use amount of the memory resource of the physical page;

if the physical memory usage of the application container exceeds the value set by the user in the process, the application container process exceeding the memory usage is killed or the operation of the application container process is paused;

statistics and limiting I/O bandwidth resources: by adding a current limiter system service between the system service of the file system and the system service of the device driver, each I/O request is captured by the current limiter system service, whether the request issuing requirement is met or not is judged according to the type and the size of the I/O request, if not, the issuing of the request is suspended, and if yes, the request is issued, and the token number in the current limiter system service is updated;

The number of tokens increases gradually as the system operates and there is an upper limit on the number of tokens, once the upper limit is reached, the number of tokens cannot continue to increase.

8. The microkernel-based container build and run system of claim 1, wherein the fail-over functional module comprises: when a fault error occurs, capturing the fault, wherein the most common fault is page fault abnormality, and after capturing, performing exit operation on the abnormal system container process, and recovering all resources;

and then sending a message for restarting the system container to the process management system container, and immediately restarting the system container after the process management system container receives the message, and reconstructing the content and inter-process communication in the system container.

9. The microkernel-based container building and running system according to claim 1, wherein the system container is located in a user state and is also managed as a container, and the CPU and memory overhead of the system service process are counted and the system service process is uniformly managed;

the system accelerates the I/O speed of the microkernel through direct memory access, manages data to be transferred by adopting capability, and directly copies the data from the device to the memory or directly writes the data from the memory to the device through direct memory access, thereby reducing the number of inter-process communication and the number of repeated memory copies.

10. A microkernel-based container construction and operation method, comprising:

namespaces function steps: dividing static system resources; dividing mounting point data, network protocol stack data and process management data, accessing different system resources by different namespaces where different application containers are located, and realizing isolation of the system resources;

control group function steps: dividing dynamic system resources, counting and limiting CPU resources, memory resources and I/O bandwidth resources, using limited resources by different control groups where different application containers are located, and realizing limitation of the system resources;

fault recovery function step: and handling the situation of system service breakdown caused by memory errors.