KR20200077115A - Method of ensuring process time by minimizing performance interference in container virtualization environment - Google Patents

Abstract

According to an embodiment of the present invention, a method for ensuring optimal processing time by minimizing performance interference in a container virtualization environment comprises: a step of measuring a performance interference value; and a container request placement step.

Description

Method of ensuring process time by minimizing performance interference in container virtualization environment}

The present invention relates to a method for ensuring optimal processing time through minimizing performance interference in a container virtualization environment.

Most of the existing container arrangement methods performed in the server cluster are performed based on server available resources, CPU and storage device hardware types, and container application type affinity. However, several containers share resources of a host, such as a kernel, and this causes interference between containers, which may degrade performance and increase processing time of container applications. Isolation of the shared resource of the host is not supported in container virtualization technology, and since there are many and various types of shared resources corresponding to performance interference, it is difficult to comprehensively respond to it, and the degree of performance interference between various container applications is different. A method for supplementing this is required.

The present invention proposes a technique for minimizing performance interference between multiple containers occurring in a single host in a cloud environment using container virtualization, and performing optimal processing time in a given environment.

In order to minimize the processing time of a container, the method measures a performance interference number between a given container application and calculates an estimated execution time of each container based on this, thereby minimizing the increase in processing time due to performance interference. To this end, the method consists of a total of two stages, each of which is (1) measuring the performance interference due to various container application combinations, and (2) utilizing it to minimize the processing time of the currently requested container among the given server clusters. Or, selecting a server that is expected to minimize overall container processing time and allocating requests. In the second step, the estimated execution time of the currently requested container and the additional execution time of the existing running container are predicted by comparing the type of the currently requested container application with the type of the container application currently running on each server. do.

This method can provide a level of performance that is as close to the original performance as possible by minimizing the additional execution time due to performance interference between containers when a service-sensitive service needs to be continuously requested and allocated in a container-based cloud. In this way, the application can be executed within a given processing time. This method can be applied when using container-level virtualization in V2X, 5G, automation process, IoT environment, etc., which is sensitive to response time, and it can reduce service response time by reducing additional processing time by minimizing performance interference between containers. It is expected to be.

1 is a timeline of a container application running on a CPU.
2 is a method for calculating a performance interference value.
3 is a method of calculating an expected execution time of a container application.
4 is a result of updating the execution time of an existing running container.
5 is a conceptual diagram illustrating an application example of a container request placement strategy.

The above-described features and effects of the present invention will become more apparent through the following detailed description in connection with the accompanying drawings, and accordingly, those skilled in the art to which the present invention pertains can easily implement the technical spirit of the present invention. Will be able to.

The present invention can be variously changed and can have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention.

In describing each drawing, similar reference numerals are used for similar components.

Terms such as first and second may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from other components.

For example, the first component may be referred to as a second component without departing from the scope of the present invention, and similarly, the second component may be referred to as a first component. The term and/or includes a combination of a plurality of related described items or any one of a plurality of related described items.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person skilled in the art to which the present invention pertains.

Terms such as those defined in a commonly used dictionary should be interpreted as having meanings consistent with meanings in the context of related technologies, and should not be interpreted as ideal or excessively formal meanings unless explicitly defined in the present application. Should not.

The suffix modules, blocks, and parts for components used in the following description are given or mixed only considering the ease of writing the specification, and do not have a meaning or a role that is distinguished from each other.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described so that those skilled in the art can easily carry out. In the following description of embodiments of the present invention, when it is determined that detailed descriptions of related well-known functions or well-known configurations may unnecessarily obscure the subject matter of the present invention, detailed descriptions thereof will be omitted.

Hereinafter, a method of guaranteeing an optimal processing time through minimizing performance interference in a container virtualization environment according to the present invention will be described.

Container is a virtualization technology that creates a lightweight virtual space by applying OS-level virtualization. The container does not have a complete operating system, unlike a virtual machine, which is a conventional virtualization technology. It uses a shared kernel with a host machine and uses a virtual space equipped with only the libraries necessary for program execution.

Containers, for example, open source projects such as Docker (Virtual Docker) virtualize the resources of the host to provide multi-tenancy and allocate them per container. At this time, resource separation technology built into the Linux kernel such as cgroup can be applied to container technology. cgroup provides the function to allocate resources such as memory and CPU Block I/O to each container independently.

Unlike virtualization used in virtual machines, cgroup-based resource virtualization is a resource isolation technology built into the kernel. Host resources that are not controlled by the cgroup, such as the CPU's cache (L1, L2, LLC, etc.), memory bandwidth, and I/O devices are shared and used by all containers, and a specific container excessively uses or occupies shared resources. If you do, the performance of other containers using the shared resource may be lowered. As a result, as the processing speed of the container application decreases, the response time of the service request also increases, and the overall quality of the service may decrease.

To solve this, the method proposes a method of optimizing the processing time of a container by measuring the performance interference number between the given container applications and scheduling the allocation of the container request to the optimal server based on the numerical values.

In this method, it is assumed that N kinds of container applications are given, and it is assumed that the degree of use of shared resources of each container is the same during the execution time (request processing time) of the container. In addition, in order to minimize CPU cache miss sharing (memory bandwidth), which is a major cause of container performance interference, it is assumed that each container uses one CPU affinity allocated exclusively through a cgroup. Also, one container exclusively executes one application.

Hereinafter, a method for ensuring optimal processing time through minimizing performance interference in a container virtualization environment according to an embodiment of the present invention will be described in detail with reference to the drawings.

1 is a timeline of a container application running on a CPU.

2 is a method for calculating a performance interference value.

<Step 1-Performance Interference Numeric Measurement Step>

In order to calculate the performance interference, a plurality of container applications are simultaneously executed to calculate the additional execution time, and the time value is divided by the execution time without performance interference. 1 and 2 show a method of calculating performance reduction values after simultaneously executing two types of container applications.

'Reference time per container application' in FIG. 2 means the original processing time when the corresponding container is executed without performance interference. At this time, when A and B are simultaneously executed as containers as shown in FIG. 1, the amount of time additionally executed in each container is calculated, and the corresponding time is divided by the original execution time to calculate the performance interference value. For example, if the original execution time of A is 2 seconds, and 2.2 seconds were taken when A and B were executed simultaneously, 0.2 / 2 = 0.1, that is, 10% of performance interference occurred, and the performance interference value is calculated as 0.1. At this time, since the section where the performance interference occurred is limited to the time when the two containers were executed simultaneously, the minimum execution time of each container application: minTime value is obtained and stored together, and the section where the performance interference does not occur is not considered. Through these values, the following performance interference record is generated.

Record format: {[application type combination], target application type, minTime, performance interference number }

Data example: {[A,B], A, 2.0, 0.1}

-The values in the above examples mean the following respectively.

(1) When A and B are executed simultaneously: [A,B],

(2) For application A : A,

(3) For 2.0 seconds (minTime): 2.0

(4) 0.1 (10%) of performance interference: 0.1

-However, when several types of applications are executed at the same time, the degree of performance interference for each type of application is different, so the target for a specific application is shown in (2) above. In this way, the case in which the target application is B in FIG. 2 can be represented as follows.

Data example: {[A,B], B, 2.0, 0.05}

-The values in the above examples mean the following respectively.

(1) When A and B are executed simultaneously: [A,B],

(2) For B application: B,

(3) For 2.0 seconds (minTime): 2.0

(4) 0.05 (5%) of performance interference: 0.05

In this way, performance interference values are calculated and stored as data for all given container application combinations. For example, given four types of container applications, for output performance interference values, the redundant combination H(4,2): 10, + H(4,3): 20, + H(4,4 ): 35 = 65 records are output. This record contains information about (1) when any combination of applications was run together, (2) how many times (3) how many seconds (4) performance interference occurred in a particular application.

-Each duplicate combination: H(n,r) indicates the number of records when r container applications are executed simultaneously when N container application types are given. Examples of each case are as follows.

-Examples of records for the case of H(4,2) are {[A,B], B, 2.0, 0.05 }.

-Examples of records for the case of H(4,3) are {[A,B,C], B, 2.0, 0.15 }.

-An example of a record for the case of H(4,4) is {[B,B,B,C], C, 2.0, 0.25}.

<Step 2-Container request placement step>

3 is a method of calculating an expected execution time of a container application.

4 is a result of updating the execution time of an existing running container.

5 is a conceptual diagram illustrating an application example of a container request placement strategy.

In the container request placement step according to an embodiment of the present invention, after obtaining the performance interference value for all cases, batch scheduling for the container request may be performed. When a container request comes in, the performance interference rate (expected execution time, or additional execution time) for each server in the server cluster is calculated, and then the container request is allocated using a specific strategy.

2- Course 1 : Estimated execution time of newly requested containers

Calculate the estimated request time for newly requested containers for all servers in the cluster. In order to calculate the expected execution time of the newly requested container, performance interference figure data output in the first step: performance interference figure when a specific combination of container applications are performed is used, an example of which is illustrated in FIG. 3. .

2- Course 2 : Update the estimated execution time of the existing container running on each server

When a new container request is allocated to a specific server, the performance of the container that was previously running is also degraded due to the execution of the new container. Therefore, the estimated execution time of the newly requested container is calculated for each server, and at the same time, the additional execution time of the container already running on the server is predicted and updated together. When requesting a new container, an example of an extended execution time of a container that is already running is illustrated in FIG. 4.

2- 3 courses : Deployment strategy for container requests

-That is, when a request for a new container arrives, two values can be calculated in advance for all servers in the cluster, and the values are as follows.

[Expected execution time A]: When a new container request is allocated to the server, the expected execution time of the container

[Expected execution time B]: When a new container request is assigned to the server, the degree of performance interference on the existing containers running on the server (additional execution time)

-Using these two values, you can devise a deployment strategy for container workloads. There are two strategies proposed in this method, which are composed as follows.

[Strategy 1] : Strategy to minimize the total processing time in consecutive container requests

-When a series of container requests arrive in succession, select the server whose sum of [Estimated execution time A] and [Estimated execution time B] is the smallest. Even if the value of [expected execution time A] calculated by a specific server is large, if the value of [expected execution time B] is small, the corresponding server may be selected. This can minimize the overall container execution time, but may not minimize the execution time of the currently requested container.

[Strategy 2] : Strategy that minimizes the execution time of the currently requested container

-When a container is already running on each server due to previously requested container requests, select the server whose value is the [estimated execution time A] for the currently requested container. As a result, it is possible to quickly perform a request for a currently arrived container, but since the additional performance interference to other containers is not taken into account, the total sum of container execution times can be increased.

-Figure 5 shows an example of applying the above two strategies. When a request for a new container occurs, the estimated execution time is calculated for each server. [Strategy 1] , which minimizes the total container processing time, selects the server 1 whose sum of [the execution time of the newly requested container + the additional execution time of the existing running container] is minimum: 6.5 seconds. [Strategy 2] , which minimizes the execution time of the currently requested container, selects Server 2 , which takes 4.0 seconds, among the two servers. At this time, [Strategy 2] may increase the overall execution time as the degree of performance interference between containers increases, but the execution time of the currently requested container may be shortened.

Claims (1)

As a method for ensuring optimal processing time through minimizing performance interference in a container virtualization environment,
Measuring a performance interference value; And
A method for guaranteeing an optimal processing time through minimizing mutual interference in a container virtualization environment characterized by including a container request placement step.

Images