Virtualization system and control method for virtualization system

Abstract

A control server according to one aspect of the present invention is provided with: a physical-virtual computation core mapping generation unit that performs mapping of an application computation core resource definition file in which the correspondence between a plurality of applications to be run in containers and virtual computation core numbers is defined, physical computation core numbers assigned to the containers, and the virtual computation core numbers associated with the applications; and an application operation computation core setting unit that fixedly associates an application to be started with the physical computation core number of an operation computation core on the basis of information about the mapping and information described in the application computation core resource definition file.

Description

Virtualization system and method for controlling virtualization system

[0001] The present invention relates to a virtualization system and a control method for a virtualization system.

[0002] In recent years, "microservice architecture" has become popular, which realizes systems by combining "microservices," each of which is independent and provides each small function, rather than realizing complex requirements in a single (monolithic) application. By adopting a microservice architecture, it becomes possible to add or change new functions on a microservice-by-microservice basis, making it easier to add or change functions to a system. Therefore, using a microservice architecture also makes it possible to expand a system in stages.

[0003] A microservice architecture can be realized, for example, by using container-based virtualization technology. Containers are independent spaces created on a host operating system (OS) using virtualization technology, allowing for the creation of an execution environment for each application managed as a "microservice" in each independent space.

[0004] In addition, in the container-based virtualization technology, multiple containers share the kernel of the host OS deployed on the hardware. Therefore, it is possible to avoid an increase in overhead due to virtualization and to efficiently utilize computer resources. When multiple containers share the host OS, the containers are associated with the central processing unit (CPU) cores that run the containers.

[0005] For example, Patent Document 1 discloses a technique in which a monitor software container scrutinizes a CPU multi-core architecture, performs a calibration method to analyze and determine the amount of CPU nodes and processor cores, etc., and applies the values ​​determined by the calibration method to a protocol container.

[0006] Special table 2019-525650 publication

[0007] In the control systems used in industrial infrastructure, a large number of applications, more than 100 in total, run. Therefore, if containers and applications are associated one-to-one, there are concerns that container control will become more complex and container configuration management will become more difficult. To address these concerns, an operating mode in which multiple applications run within a single container can be considered.

[0008] In an operation mode in which multiple applications run within a single container, the applications can be prevented from interfering with each other by isolating the computer resources used by each application. Separation of the computer resources used by each application can be achieved, for example, by fixedly associating each application within a container with the CPU core on which the application runs.

[0009] However, when such correspondence is made, problems may arise when porting the container to another virtualization system. Specifically, if the CPU core number associated with an application has already been assigned as the operating CPU for another container in the destination virtualization system, the application cannot be run in that virtualization system. In other words, if each application running in a container is fixedly associated with the operating CPU core for that application, the portability of the container is reduced.

[0010] The present invention has been made in consideration of the above circumstances, and an object of the present invention is to prevent interference between applications in a container while maintaining the portability of the container.

[0011] A virtualization system according to one aspect of the present invention includes a definition file that defines the correspondence between a plurality of applications to be run within a container of a virtualization system constructed using container-based virtualization technology and virtual computation core numbers, which are the numbers of virtual computation cores; a mapping generation unit that maps physical computation core numbers, which are the numbers of physical computation cores assigned to the container, to the virtual computation core numbers associated with the applications in the definition file; and an operating computation core setting unit that fixedly corresponds an application to be launched with the physical computation core number of the operating computation core that runs the application based on the mapping information and the contents of the definition file.

[0012] According to at least one aspect of the present invention, it is possible to prevent interference between applications in a container while maintaining the portability of the container. Problems, configurations, and effects other than those described above will become clear from the description of the following embodiments.

[0013] FIG. 1 is a block diagram showing an example of the functional configuration of a control server according to one embodiment of the present invention. FIG. 2 is a block diagram showing an example of the hardware configuration of a control server according to one embodiment of the present invention. FIG. 3 is a diagram showing an example of a display of a settings screen on which the correspondence between applications and virtual CPU core numbers is set according to one embodiment of the present invention. FIG. 4 is a diagram showing an example of the correspondence between application tasks and virtual CPU core numbers based on the settings made via the settings screen shown in FIG. 3 according to one embodiment of the present invention. FIG. 5 is a conceptual diagram of virtual CPU core numbers managed by an application management mechanism unit according to one embodiment of the present invention. FIG. 6 is a diagram showing example 1 of mapping by a physical-virtual CPU core mapping generator according to one embodiment of the present invention. FIG. 7 is a diagram showing example 2 of mapping by a physical-virtual CPU core mapping generator according to one embodiment of the present invention. FIG. 8 is a flowchart showing an example of the procedure for control processing of a virtualization system by a control server according to one embodiment of the present invention.

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In each drawing, the same components are designated by the same reference numerals. The following description and drawings are examples for explaining the present invention, and for clarity of explanation, appropriate omissions and simplifications have been made. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0015] <Control Server Configuration> First, the configuration of the control server on which the virtualization system of this invention is built will be described with reference to Figure 1. Figure 1 is a block diagram showing an example of the functional configuration of a control server 100 according to one embodiment of the present invention. In this embodiment, a virtualization system using container-based virtualization technology is built on the control server 100.

[0016] As shown in FIG. 1 , the control server 100 includes a Pod 10 , a container engine 20 , and a container execution platform control mechanism unit 30 .

[0017] [Pod] A Pod 10 is the smallest unit that controls the launch of an application, and is made up of multiple containers 1-1 to 1-n (n is a natural number equal to or greater than 2). In the following description, when it is not necessary to distinguish between the containers 1-1 to 1-n, they will be collectively referred to as container 1.

[0018] The containers contained within a Pod 10 share various resources and networks (not shown). Note that while Fig. 1 shows an example in which the control server 100 contains one Pod 10, the present invention is not limited to this; the control server 100 may contain multiple Pods.

[0019] [Container] The container 1 includes a container image 11 and an application management mechanism unit 12. The container image 11 is an operating environment template for running the container 1, and includes an application CPU core allocation definition file fc and multiple applications Ap-1 to Ap-m (m is a natural number greater than or equal to 2). In the following description, when there is no need to individually identify the applications Ap-1 to Ap-m, they are collectively referred to as application Ap. The container image 11 also includes operating system (OS) libraries, dependency relationship information (not shown), and the like required to run the application Ap.

[0020] The application Ap is included in advance in the container image 11, and is launched as an application within the container 1 by the application execution unit 123 of the application management mechanism 12. In the following description, a process, which is the smallest execution unit of the application Ap, is referred to as a "task." The application management mechanism 12 executes the application within the container 1 based on the contents of the application CPU core allocation definition file fc.

[0021] The application CPU core allocation definition file fc (an example of a definition file) is a file created in advance by a user. The application CPU core allocation definition file fc describes correspondence information between each application running in the container 1 and the CPU core number (an example of a computing core) of each operating CPU running these applications.

[0022] The CPU core numbers associated with applications in the application CPU core allocation definition file fc are not physical CPU core numbers (hereinafter referred to as "physical CPU core numbers"), but virtual CPU core numbers (hereinafter referred to as "virtual CPU core numbers"). The virtual CPU core numbers are virtual CPU numbers that are determined relatively in accordance with the number of physical CPU cores assigned to the container 1. In this way, by managing applications in association with virtual CPU core numbers, it becomes possible to specify the operating core CPU of an application without depending on the number of CPUs on the container host side or the physical CPU core number on which the container 1 is placed.

[0023] An example of the settings of the application CPU core allocation definition file fc will be described in detail with reference to Figure 3, and an example of the correspondence between applications and operating CPU cores based on the definition contents of the application CPU core allocation definition file fc will be described in detail with reference to Figure 4 described below.

[0024] The application management mechanism 12 includes a physical-virtual CPU core mapping generation unit 121 , an application running CPU setting unit 122 , and an application execution unit 123 .

[0025] Note that information about the application management mechanism 12 is not included in the container image 11, but is instead placed as a binary executable file (hereinafter referred to as "executable binary") on the container host (not shown). The container host is a general term for the OS and device (control server 100) on which the container 1 and Pod 10 run. The application management mechanism 12 is dynamically mounted (inserted) into the container 1 when the container 1 starts up, and starts up as the entry process of the container 1. Figure 1 shows the state after the application management mechanism 12 has been mounted on the container 1.

[0026] The container 1 is started by an instruction from the container execution unit 23 in the container engine 20, and the container execution unit 23 instructs the container 1 to start by referring to the configuration information 22. In the configuration information 22, the application management mechanism unit 12 is set as the entry point process of the container 1. As a result, when the container 1 is started, the application management mechanism unit 12 is mounted in the container 1 and started as the entry process of the container 1.

[0027] The setting of the entry point process of the container 1 to the application management mechanism unit 12 is performed by the Pod container registration unit 31 of the container execution platform control mechanism unit 30. More specifically, this setting is performed by the Pod container registration unit 31 specifying, to the Pod container management unit 21, a command line including information about the placement location of the application management mechanism unit 12 within the container 1.

[0028] The physical-virtual CPU core mapping generator 121 (an example of a mapping generator) of the application management mechanism 12 creates a mapping (not shown) between the physical CPU core numbers and the virtual CPU core numbers assigned to the container 1. The mapping generated by the physical-virtual CPU core mapping generator 121 is stored for each application in the form of, for example, a table. Examples of mapping by the physical-virtual CPU core mapping generator 121 will be described in detail with reference to FIGS. 5 to 7 below.

[0029] The application operating CPU setting unit 122 (an example of an operating computation core setting unit) fixedly associates the physical CPU core number of the application's operating CPU core with the application based on the mapping information and the definition contents of the application CPU core allocation definition file fc.

[0030] The application execution unit 123 starts and executes the application in the container 1 based on the contents of the application CPU core allocation definition file fc.

[0031] [Container Engine] The container engine 20 includes a Pod container management unit 21, configuration information 22, and a container execution unit 23. The Pod container management unit 21 configures the configuration information 22 based on information about the Pod 10 and the container 1 registered by the Pod container registration unit 31 of the container execution platform control mechanism unit 30. The Pod container management unit 21 also changes the content of the configuration information 22 based on change information about the configuration of the Pod 10 and / or the container 1 input from the Pod container registration unit 31.

[0032] The configuration information 22 is a file that describes information about the configuration of the Pod 10 and the container 1, information about the storage location of the container image 11, etc. The container execution unit 23 starts (executes) the Pod 10 and the container 1 by referring to the information described in the configuration information 22 in accordance with an instruction from the Pod execution instruction unit 32 of the container execution platform control mechanism unit 30.

[0033] [Container Execution Platform Control Mechanism] The container execution platform control mechanism 30 is an interface for operating containers in the Pod 10 , and includes a Pod container registration unit 31 and a Pod execution instruction unit 32 .

[0034] Based on instructions input by the user, the Pod container registration unit 31 refers to the Pod definition file fp and instructs the container engine 20 to register the Pod 10 and the container 1. The Pod definition file fp is a file that describes information about the settings of each container 1 to be included in the Pod 10, and is created in advance by the user.

[0035] The Pod execution instruction unit 32 instructs the container engine 20 to start the Pod 10 and the container 1, etc., based on instructions from the user.

[0036] <Example of Computer Hardware Configuration> Next, the hardware configuration of a device that implements the functions of the control server 100 according to this embodiment will be explained with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the hardware configuration of the control server 100. The computer 200 shown in Fig. 2 is hardware used as a so-called computer.

[0037] The computer 200 includes a control unit 210, a nonvolatile storage 220, a display unit 230, an operation input unit 240, and a communication I / F (Interface) 250, which are all connected to a bus B.

[0038] The control unit 210 includes a CPU (Central Processing Unit) 211 , a ROM (Read Only Memory) 212 , and a RAM (Random Access Memory) 213 .

[0039] The CPU 211 reads out program code of software that realizes each function according to this embodiment from the ROM 212, expands it in the RAM 213, and executes it. Variables, parameters, etc. that are generated during the calculation process are temporarily written to the RAM 213.

[0040] The control unit 210 may include a processing device such as an MPU (Micro-Processing Unit) instead of the CPU 211. Alternatively, the control unit 210 may use both a CPU and an MPU.

[0041] The nonvolatile storage 220 may be, for example, a hard disk drive (HDD), a solid state drive (SSD), a flexible disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a nonvolatile memory card, etc. In addition to the OS and various parameters, the nonvolatile storage 220 also stores programs for operating the computer 200. The programs may also be stored in the ROM 212.

[0042] The display unit 230 is a monitor configured, for example, by an LCD (Liquid Crystal Display) or the like, and displays the results of processing performed by the computer 200. The operation input unit 240 is configured, for example, by a keyboard, a mouse, a touch sensor, or the like, and generates operation signals in response to user operations and supplies the operation signals to the CPU 211. The display unit 230 and the operation input unit 240 may be integrated into a touch panel. The computer 200 may also be configured without the display unit 230 or the operation input unit 240.

[0043] The program is stored in the form of a computer-readable program code, and the CPU 211 sequentially executes operations in accordance with the program code. In other words, the ROM 212 or the non-volatile storage 220 is used as an example of a computer-readable non-transitory recording medium that stores a program to be executed by a computer.

[0044] The communication I / F 250 may be, for example, a network interface card (NIC), and may transmit and receive various data to and from external devices via a network or communication line.

[0045] <Example of Setting Correspondence Between Applications and Virtual CPU Core Numbers in Application CPU Core Allocation Definition File> Next, an example of setting correspondence between applications and virtual CPU core numbers in the application CPU core allocation definition file fc will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of display of a setting screen Sc1 on which correspondence between applications and virtual CPU core numbers is set. In this embodiment, various setting files such as the application CPU core allocation definition file fc are written in, for example, YAML (YAML Int Markup Language) format.

[0046] 3, the top row of the setting screen Sc1 has a description "tasks." In the "tasks" item, applications managed by the application management mechanism unit 12 are defined.

[0047] The "tid" field specifies the ID (identifier) ​​of a task (process) executed in an application. Four task IDs, "taskA" to "taskD," are specified on the setting screen Sc1 in FIG. 3. The following explanation uses the setting of "taskA" as an example.

[0048] "Command" is a command that indicates the description of the setting definition, and the definitions of the setting items "type" and "execStart" are described in the setting screen Sc1 shown in Fig. 3. The "type" item defines the type of application, and the "execStart" item specifies the execution command for starting the application.

[0049] The "simple" application type is set for applications that do not require strict startup synchronization with other tasks. Other application types include "oneshot" and "forking."

[0050] "Oneshot" is a type that is set for applications that run only when the container is started and do not remain resident. "Forking" is a type that is set for applications with a program structure that forks after the application startup initialization process is complete and continues the main processing in the child process. "Fork" is a system call that branches the parent process into two processes with the same content.

[0051] The "resource" item sets information about the computer resources to be allocated to the application. The following "cpuset" item specifies the CPU core on which the application runs by using a virtual CPU core number. The virtual CPU core numbers are expressed, for example, in ASCII (American Standard Code for Information Interchange) format, separated by commas (,"), and the range of virtual CPU core numbers to be allocated is indicated by a dash ("-"). For example, if "0-2,4" is written in the "cpuset" item, then "0", "1", "2", and "4" will be used as virtual CPU core numbers.

[0052] In the setting screen Sc1 shown in FIG. 3, a virtual CPU core number of "0" is assigned to a task (hereinafter also referred to as "task A") that has been assigned a task ID of "taskA." With this setting, core "0" of the container host CPU (operating CPU) is assigned to task A. By assigning a virtual CPU core number to each task of an application via the setting screen Sc1 or the like, it becomes possible to specify the operating CPU core for the task of the application without changing the implementation of the application itself.

[0053] Fig. 4 is a diagram showing an example of the correspondence between application tasks and virtual CPU core numbers based on the settings made via the setting screen Sc1 shown in Fig. 3. In Fig. 4, "vCPU" indicates the virtual CPU core number.

[0054] 4, the virtual CPU core number "0" is assigned to task A and task B running in container 1. In this way, according to this embodiment, a specific virtual CPU core (numbered "0") can be shared by multiple tasks (task A and task B).

[0055] 4, task C is assigned the virtual CPU core number "1," and task D is assigned the virtual CPU core numbers "2" and "3." In other words, according to this embodiment, it is also possible to assign multiple virtual CPU core numbers ("2" and "3") to one task (task D).

[0056] In this way, by explicitly specifying the operating CPU core for the application's tasks via the setting screen Sc1, it is possible to limit the operating CPU core for the application's tasks to only those specified by the virtual CPU core number. In other words, according to this embodiment, it is possible to clearly separate the computer resources used by the application. Note that, as also shown in FIG. 4 , the virtual CPU cores used by each task of the application must be limited to the range of physical CPU cores allocated to container 1. In other words, the number of virtual CPU cores used by each task of the application must be set to a number equal to or less than the number of physical CPU cores allocated to container 1. In other words, the number of virtual CPU cores allocated to a task cannot be greater than the number of physical CPU cores pre-allocated to container 1.

[0057] Next, the concept of the virtual CPU core number managed by the application management mechanism unit 12 will be described with reference to Fig. 5. Fig. 5 is a conceptual diagram of the virtual CPU core number managed by the application management mechanism unit 12.

[0058] The physical-virtual CPU core mapping generation unit 121 (see FIG. 1) associates the physical CPU core numbers with the virtual CPU core numbers in accordance with, for example, the following rules (1) and (2).

[0059] (1) The virtual CPU core numbers are assigned in order starting from "0" (zero). (2) The virtual CPU core numbers are assigned in order starting from the smallest physical CPU core numbers assigned to container 1.

[0060] 5 shows that physical CPU core numbers "0" and "1" in the container host are assigned to the OS cores, and physical CPU core numbers "2" and onwards are assigned to container a. In this case, the physical-virtual CPU core mapping generator 121 creates a mapping by assigning physical CPU core numbers "2" and onwards in order from virtual CPU core number "0". In the example shown in FIG. 5, the physical-virtual CPU core mapping generator 121 assigns virtual CPU core numbers "0" to "3" to physical CPU core numbers "2" to "5", respectively.

[0061] Fig. 6 is a diagram showing mapping example 1 by the physical-virtual CPU core mapping generator 121, and Fig. 7 is a diagram showing mapping example 2. In the example shown in Fig. 6, the physical CPU core numbers assigned to container 1 are "2" and "3." In this case, the physical-virtual CPU core mapping generator 121 can assign, for example, the physical CPU core number "2" to the virtual CPU core number "0" and the physical CPU core number "3" to the virtual CPU core number "1."

[0062] 7, the physical CPU core numbers assigned to container 1 are "1" and "3." In other words, non-consecutive physical CPU core numbers are assigned to container 1. In this case, the physical-virtual CPU core mapping generation unit 121 can, for example, assign the physical CPU core number "1" to the virtual CPU core number "0" and assign the physical CPU core number "3" to the virtual CPU core number "1."

[0063] The mapping by the physical-virtual CPU core mapping generation unit 121 is performed only once, after the container 1 is started and before the application is started. After that, the application execution unit 123 executes the application by referring to the generated mapping information.

[0064] <Virtualization System Control Method by Control Server> Next, a virtualization system control method by the control server 100 according to this embodiment will be described with reference to Fig. 8. Fig. 8 is a flowchart showing an example of the steps in the control process of the virtualization system by the control server 100.

[0065] First, the correspondence between each application running in the container 1 and the virtual CPU core number of the CPU running each application is defined in the application CPU core allocation definition file fc (step S1). The processing of step S1 is performed based on instructions from the user.

[0066] Next, the physical-virtual CPU core mapping generator 121 of the application management mechanism 12 creates a mapping between the physical CPU core numbers pre-assigned to the container 1 and the virtual CPU core numbers (step S2). The association between the container 1 and the physical CPU core numbers is defined in the Pod definition file fp (see FIG. 1).

[0067] Next, the application operating CPU setting unit 122 fixes the operating CPU core of the application based on the definition content in the application CPU core allocation definition file fc and the mapping information generated in step S2 (step S3). In step S3, the application operating CPU setting unit 122 specifies a physical CPU core number, thereby fixedly associating the operating CPU core of the application with the CPU core having the specified physical CPU core number.

[0068] Next, the application execution unit 123 references the application CPU core allocation definition file fc and starts the application to be started in the container 1 (step S4). The application started in step S4 is executed on the operating CPU core associated with the application by specifying the physical CPU core number in step S3.

[0069] In the embodiment described above, the control server 100 on which the virtualization system is built has an application CPU core allocation definition file fc, which defines the correspondence between multiple applications to be run in container 1 and virtual CPU core numbers. The control server 100 also has a physical-virtual CPU core mapping generator 121, which maps the physical CPU core numbers assigned to container 1 to the virtual CPU core numbers associated with the applications in the application CPU core allocation definition file fc. The control server 100 also has an application operating CPU setting unit 122, which fixedly associates the applications to be launched with the physical CPU core number of the operating CPU that runs the applications, based on the mapping information and the contents of the application CPU core allocation definition file fc.

[0070] Therefore, in this embodiment, the operating CPU cores of the applications running in the container 1 are reliably separated for each application. This prevents problems such as interference between applications caused by containerization. Therefore, according to this embodiment, it is possible to achieve low overhead in application execution and build a virtualization system with high real-time capabilities.

[0071] In this embodiment, a virtual CPU core number is assigned to the application, and mapping to a physical CPU core is performed after the container 1 is started. Therefore, migration to another virtualization system can be performed smoothly. In other words, the portability of the virtualization system can be maintained.

[0072] Note that in the above-described embodiment, it is assumed that the number of physical CPU cores assigned to container 1 is static, and mapping by the physical-virtual CPU core mapping generation unit 121 is performed only once, after container 1 is started and before an application is started. However, the present invention is not limited to this. The physical-virtual CPU core mapping generation unit 121 may generate mapping each time an application is started or restarted. By performing such control by the physical-virtual CPU core mapping generation unit 121, even if the physical CPU cores assigned to container 1 change dynamically, it becomes possible to appropriately map virtual CPU core numbers associated with applications to dynamically changing physical CPU numbers.

[0073] Furthermore, the above-described embodiment has described the system configuration in detail and specifically to clearly explain the present invention, and is not necessarily limited to a system having all of the described configurations. The control lines or information lines indicated by solid lines or arrows in Figures 1 and 2 indicate those considered necessary for explanation, and do not necessarily represent all of the control lines or information lines in the product. In reality, it can be considered that almost all of the configurations are interconnected.

[0074] In addition, in this specification, processing steps describing chronological processing include not only processing that is performed chronologically in the order described, but also processing that is not necessarily performed chronologically but is performed in parallel or individually (for example, parallel processing or processing by objects).

[0075] DESCRIPTION OF SYMBOLS 1...container, 10...Pod, 11...container image, 12...application management mechanism, 20...container engine, 21...Pod container management unit, 22...configuration information, 23...container execution unit, 30...container execution platform control mechanism, 31...Pod container registration unit, 32...Pod execution instruction unit, 100...control server, 121...physical virtual CPU core mapping generation unit, 122...application operation CPU setting unit, 123...application execution unit

Claims

1. A virtualization system comprising: a definition file that defines the correspondence between multiple applications to be run within a container of a virtualization system built using container-type virtualization technology and virtual processing core numbers, which are the numbers of virtual processing cores; a mapping generation unit that maps physical processing core numbers, which are the numbers of physical processing cores assigned to the container, to the virtual processing core numbers associated with the applications in the definition file; and an operating processing core setting unit that, based on the mapping information and the contents of the definition file, fixedly corresponds the applications to be launched to the physical processing core numbers of the operating processing cores that run the applications.

2. The virtualization system according to claim 1, further comprising an application execution unit that references the definition file and starts the application to be started in the container.

3. The virtualization system described in claim 2, wherein the operation calculation core setting unit fixedly corresponds the physical calculation core number mapped to the virtual calculation core number associated with the application in the definition file to the operation calculation core of the application.

4. The virtualization system according to claim 3, wherein the virtual processing core number is a processing core number determined relatively in accordance with the number of the physical processing cores assigned to the container.

5. The virtualization system according to claim 4, wherein the number of virtual processing core numbers associated with the application in the definition file is set to a number equal to or less than the number of physical processing cores assigned to the container.

6. The virtualization system according to claim 5, wherein the correspondence relationship between the applications and the virtual processing core numbers in the definition file is one-to-one, one-to-many, or many-to-one.

7. The virtualization system according to claim 6, wherein the mapping generation unit creates the mapping after the container is started and before the application is started.

8. The virtualization system according to claim 6, wherein the mapping generation unit creates the mapping each time the application is started or restarted.

9. A method for controlling a virtualization system, comprising the steps of: defining in a definition file the correspondence between a plurality of applications to be run within a container of a virtualization system constructed using container-type virtualization technology and virtual processing core numbers, which are the numbers of virtual processing cores; mapping physical processing core numbers, which are the numbers of physical processing cores assigned to the container, and the virtual processing core numbers associated with the applications in the definition file; and fixedly associating the applications to be launched with the physical processing core numbers of the operating processing cores that run the applications, based on the mapping information and the contents of the definition file.

Images