Virtualization system, and control method of virtualization system

Abstract

To provide a virtualization system using a container-based virtualization technique capable of swiftly notifying abnormalities that occur in an application.SOLUTION: A control server 100 in a disclosed embodiment, in which a virtualization system is built, includes an application management unit 12 that activates multiple applications Ap based on the contents of the application startup monitoring definition file and deals with the abnormal termination of an activated application Ap. The application management unit 12 is mounted on an application container 1 when the application container 1, which runs application Ap, starts and is activated as the entry point process of application container 1.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] In recent years, "microservice architecture" has become popular, where systems are created by combining "microservices," each of which is independent and provides each small function, rather than implementing 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] Microservice architecture can be realized, for example, by using container-based virtualization technology. Containers are independent spaces created on a host operating system using virtualization technology, making it possible to create an execution environment for each application managed as a "microservice" in each independent space.

[0004] Anomalies (failures) in a system built using containers can be detected using techniques such as polling. For example, Patent Document 1 describes a virtualization system fault isolation device equipped with an anomaly detection unit. The anomaly detection unit described in Patent Document 1 sends a predetermined command to a Pod on a worker node by polling, and determines whether the system is normal or abnormal based on the response returned from the Pod in response to the command. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2023 / 275985 Summary of the Invention [Problem to be solved by the invention]

[0006] However, when a system virtualized using container technology is, for example, a control system in industrial infrastructure, an anomaly detection method using polling may not meet the requirements for anomaly detection. This is because control systems operating in industrial infrastructure, etc., are required to immediately detect anomalies and quickly take measures to address the anomalies to ensure the safety of users. However, Patent Document 1 does not describe any anomaly detection methods other than polling.

[0007] The present invention has been made in consideration of the above situation, and an object of the present invention is to enable a rapid response to an abnormality that occurs in an application in a virtualization system that uses container-based virtualization technology. [Means for solving the problem]

[0008] A virtualization system according to one aspect of the present invention includes an application launch monitoring definition file that describes settings related to the launch of multiple applications and actions to be taken when an application abnormally terminates, and an application management mechanism that launches multiple applications based on the contents of the application launch monitoring definition file, detects the termination of the launched applications, and takes action when an application abnormally terminates. The application management mechanism is mounted on an application container when the application container in which the application is executed is launched, and is launched as an entry point process of the application container. [Effects of the Invention]

[0009] According to at least one aspect of the present invention, it becomes possible to quickly respond to an abnormality that occurs in an application in a virtualization system that uses container-based virtualization technology. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 2 is a block diagram illustrating an example of the functional configuration of a control server according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram illustrating an example of the hardware configuration of a control server according to an embodiment of the present invention. [Figure 3] 10 is a diagram showing an example of a display of a setting screen on which the application startup order in the application startup monitoring definition file according to an embodiment of the present invention is set. FIG. [Figure 4] 10 is a diagram showing an example of a display of a setting screen on which an FB policy is set in an application launch monitoring definition file according to an embodiment of the present invention. FIG. [Figure 5] FIG. 10 is a diagram showing an example of a setting screen on which a pod definition file is set according to an embodiment of the present invention. [Figure 6] FIG. 10 is a diagram showing an example of a display of a setting screen on which event handling rules are set according to an embodiment of the present invention. [Figure 7] 10 is a flowchart illustrating an example of a control process procedure when a pod and a container are started according to an embodiment of the present invention. [Figure 8] 10 is a flowchart illustrating an example of a procedure for a control process performed by an application management mechanism according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an example of a control processing procedure by a pod management container according to an embodiment of the present invention. [Figure 10] 10 is a flowchart illustrating an example of a procedure for control processing by a microservice execution management infrastructure unit 20 according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0011] 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.

[0012] <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.

[0013] As shown in FIG. 1, the control server 100 includes a Pod 10, a microservice execution management infrastructure unit 20, an OS event detection unit 30, an OS event monitoring unit 40, a container engine 50, and a container execution infrastructure control mechanism unit 60.

[0014] Pod 10 is the smallest unit that controls the startup of an application, and is composed of one or more containers. In this embodiment, the containers that make up Pod 10 are multiple application containers 1-1 to 1-n (n is a natural number greater than or equal to 2) and a Pod management container 2. In the following description, when it is not necessary to distinguish between the application containers 1-1 to 1-n, they will be collectively referred to as application container 1.

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

[0016] [Pod] The Pod 10 includes a plurality of application containers 1 and a Pod management container 2. The Pod management container 2 (an example of a management container) is a container that manages the application containers 1.

[0017] (Application Container) The application 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 application container 1, and includes an application launch monitoring 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.

[0018] The application Ap is written in the form of source code in the container image 11, and is launched as an application within the application container 1 by the application execution unit 121 of the application management mechanism unit 12. In the following description, a process, which is the smallest execution unit of the application Ap, is also referred to as a "task." The application management mechanism unit 12 launches the application based on the contents of the application launch monitoring definition file fc.

[0019] The application launch monitoring definition file fc is a file created in advance by the user. The application launch monitoring definition file fc defines settings related to the launch of applications in the application container 1, and a fallback (FB) policy to be applied when the termination of an application is detected. An example of the definition of the application launch order in the application launch monitoring definition file fc will be described in detail later with reference to FIG. 3.

[0020] The application management mechanism 12 (an example of an application management mechanism) includes an application execution unit 121 and an application monitoring unit 122. 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 an "executable binary") on a container host (not shown). The container host is a general term for the OS and device (control server 100) on which the application container 1 and Pod management container 2 run. The application management mechanism 12 is dynamically mounted (inserted) into the application container 1 when the application container 1 starts up, and starts up as the entry process of the application container 1. FIG. 1 shows the state after the application management mechanism 12 has been mounted on the application container 1.

[0021] The application container 1 is started in response to an instruction from a container execution unit 503 in the container engine 50, and the container execution unit 503 instructs the application container 1 to start by referencing configuration information 502. In the configuration information 502, the application management mechanism unit 12 is set as the entry point process of the application container 1. As a result, when the application container 1 is started, the application management mechanism unit 12 is mounted in the application container 1 and starts as the entry process of the application container 1.

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

[0023] The application execution unit 121 of the application management mechanism unit 12 controls the startup, startup order, startup timing, etc. of applications running in the application container 1 based on the contents of the application startup monitoring definition file fc. The application monitoring unit 122 then monitors the status of the applications started by the application execution unit 121 as child processes.

[0024] The application monitoring unit 122 also detects the termination of an application started by the application execution unit 121. For example, the application monitoring unit 122 detects the termination of an application that is being monitored as a child process based on the reception of a SIGCHILD signal from the child process. In this embodiment, the application monitoring unit 122 can also monitor grandchild processes and great-grandchild processes by using the prctl(PR_SET_CHILD_SUBREAPER) function of Linux (registered trademark). Note that the method for managing child, grandchild, and great-grandchild processes is not limited to this example, and other methods may be used.

[0025] When the application monitor 122 detects the termination of an application, it checks the cause of the application termination and handles the termination according to the cause. The handling content corresponding to the termination cause is defined as an FB policy in the application launch monitoring definition file fc. The FB policy includes, for example, information such as the restart policy and fallback level of the application.

[0026] The "restart policy" specifies the restart conditions and timing for an application when it is terminated. The "fallback level" specifies the policy for continuing operation of other applications running in the same application container 1 when the terminated application is not restarted and the target application is stopped.

[0027] The application monitoring unit 122 detects an abnormal termination of an application when the cause of the application termination is other than the cause of the termination to be restarted, or when the number of times the application is restarted within a specified time exceeds the upper limit. Then, in response to the detection of the abnormal termination, the application monitoring unit 122 performs an action (handling) defined as a fallback level. The actions defined as fallback levels include, for example, restarting the application or forcibly stopping the application container 1.

[0028] On the other hand, if the cause of termination of the application is the cause of termination that is subject to restart and the number of restarts of the application does not exceed the upper limit, the application monitor 122 restarts the application based on the restart policy.

[0029] Furthermore, the application monitoring unit 122 notifies the Pod management container 2 of the abnormal termination event as an event. An event is composed of, for example, an event ID as an identifier, a character string (message) describing the event, and a body in which additional information about the event is described. The event ID is composed of an event identifier, information indicating the type of event, and information indicating the level of the event. The event level is information indicating the urgency of dealing with the event, and includes, for example, "Critical," "Error," "Warning," "Notice," and "Info."

[0030] "Critical" is the level set for events that indicate serious errors that require some kind of immediate action, while "Error" is the level set for events such as system failures that require some kind of action depending on the situation. "Warning" is the level set for events that are issued when an event is detected that may lead to a failure over time, even though the system can continue to operate. "Notice" is the level set for events that are issued when an event that requires notification occurs, even though the system can continue to operate. "Info" is the level set for events that are intended only for event recording and notification.

[0031] That is, according to this embodiment, detailed information about an event in which an abnormality is confirmed by the application monitoring unit 122 is notified as an event to the Pod management container 2. Note that the configuration of the event is not limited to the above-described example, and the setting example of the event level is also not limited to the above-described example.

[0032] [Role of the Application Management Department] Here, the reason why the application container 1 according to this embodiment includes the application management mechanism unit 12 will be explained. In conventional technology, it has been common to run one application in one container and start and link multiple containers to configure a system. However, in control systems used in industrial infrastructure, an extremely large number of applications, such as 100 or more, run. Therefore, if containers and applications are associated one-to-one, there are concerns that container control will become complicated and container configuration management will become difficult.

[0033] One possible solution to these concerns is to operate multiple applications within a single container. When operating in this manner, the reliability of the entry point process that is generated after the container is started is particularly important. This is because the entry point process executes processes necessary for the application's task execution, such as initialization. In addition, specifications may be designed to forcibly shut down the container itself if the entry point process in a container stops, so it is important that the entry point process runs normally.

[0034] In this embodiment, the application execution unit 121 of the application management mechanism unit 12 centrally generates and executes the entry point processes of each of the multiple application containers 1. Such control by the application execution unit 121 can improve the reliability of the execution of the entry point processes of the application containers 1.

[0035] As described above, the application management mechanism unit 12 according to this embodiment is a program that runs in the application container 1, but is not included in the container image 11 and is placed as an executable binary on the container host. The application management mechanism unit 12 is dynamically mounted (inserted) into the application container 1 when the application container 1 is started, and starts as an entry process of the application container 1.

[0036] Therefore, according to this embodiment, even if the application management mechanism unit 12 is modified, it is only necessary to modify the contents of the executable binary of the application management mechanism unit 12. In other words, unlike when information about the application management mechanism unit 12 is included in the container image 11 in advance, it is not necessary to recreate the application container 1 itself generated from the container image 11.

[0037] Furthermore, by not including the application management mechanism 12 in the container image 11, it is possible to easily unify the versions of the multiple application management mechanism units 12 included in the Pod 10. This allows the versions of the multiple application management mechanism units 12 running on the same OS to be unified to the same version. Therefore, according to this embodiment, application developers can also save the effort of creating applications that take into account the coexistence of multiple versions.

[0038] (Pod management container) The Pod management container 2 is a container that detects and manages abnormalities in the application container 1 in the Pod 10. The Pod management container 2 is added to each Pod 10 as a sidecar container.

[0039] By configuring the Pod management container 2 in this manner, when the Pod management container 2 is modified, there is no need to recreate the application container 1 itself generated from the container image 11. It also becomes easy to unify the versions of multiple Pod management containers 2 running on the same OS to the same version. Therefore, according to this embodiment, application developers can save the effort of creating applications that take into account the coexistence of multiple versions.

[0040] The pod management container 2 includes an intra-pod container monitoring unit 21 and an intra-pod event receiving unit 22. The intra-pod container monitoring unit 21 receives events transmitted from the application monitoring unit 122 of each application container 1. The intra-pod container monitoring unit 21 then outputs information about the received events to the intra-pod event receiving unit 22.

[0041] When the intra-pod event receiver 22 receives an event from the intra-pod container monitor 21, it handles the event based on the FB policy preset for the application container 1 that sent the event. The FB policy for each application container 1 is defined in advance in the pod definition file fp. An example of a user definition of the pod definition file fp will be described in detail later with reference to FIG. 5.

[0042] The handling performed by the intra-pod event receiver 22 includes, for example, forcibly terminating the application container 1 in which an abnormality is detected, and forcibly terminating other application containers 1 in the Pod 10. In other words, the intra-pod event receiver 22 controls abnormality handling on a per-application container 1 or Pod 10 basis. Note that the intra-pod event receiver 22 does not analyze the contents of the application, but manages the status of the application container 1 or Pod 10, and records and stores detailed information such as a failure log.

[0043] Furthermore, the intra-pod event receiver 22 transmits the anomaly detection event as an event to the microservice execution management infrastructure unit 20.

[0044] [Microservice Execution Management Infrastructure Department] The microservice execution management infrastructure unit 20 (an example of a service execution management infrastructure unit) is a functional unit that manages the Pods 10 within the control server 100 and centrally manages events. The microservice execution management infrastructure unit 20 includes a Pod monitoring unit 201 and an in-system event management unit 202.

[0045] The pod monitor 201 outputs the event information transmitted from the intra-pod event receiver 22 of the pod management container 2 to the intra-system event manager 202 .

[0046] The system event management unit 202 centrally manages events input from the Pod monitoring unit 201 or the OS event monitoring unit 40. The system event management unit 202 also executes an action (handling) associated with an event in accordance with an event handling rule Rc defined in advance by the user. Actions performed by the system event management unit 202 include, for example, forcibly stopping the container host OS, and powering off or restarting the control server 100. An example of a user-defined event handling rule Rc will be described in detail later with reference to FIG. 6.

[0047] The OS event detector 30 detects the occurrence of events (hereinafter referred to as "OS events") such as abnormalities in the execution platform on which the Pod 10 and containers run. Events detected by the OS event detector 30 include, for example, a failure in the nonvolatile storage 220 (see FIG. 2) of the control server 100 and a failure related to a network (not shown).

[0048] The OS event monitor 40 (an example of an event monitor) receives OS events detected by the OS event detector 30 and outputs them to the system event manager 202 of the microservice execution management infrastructure 20. More specifically, the OS event monitor 40 reconstructs information on faults detected by the OS event detector 30 from various targets using various detection methods into information on events that can be managed by the system event manager 202 and outputs the information to the system event manager 202.

[0049] [Container Engine] The container engine 50 includes a Pod container management unit 501, configuration information 502, and a container execution unit 503. The Pod container management unit 501 configures the configuration information 502 based on the information about the Pod 10 and the container registered by the Pod container registration unit 601 of the container execution infrastructure control mechanism unit 60. In addition, the Pod container management unit 501 changes the contents of the configuration information 502 based on change information about the configuration of the Pod 10 and / or the container input from the Pod container registration unit 601.

[0050] The configuration information 502 is a file that contains information about the configuration of Pod 10, application container 1, and Pod container 2, the storage location of container image 11, and the like. The container execution unit 503 starts the application container 1 and the Pod management container 2 by referring to the information described in the configuration information 502 in accordance with instructions from the Pod execution instruction unit 602 of the container execution infrastructure control mechanism unit 60.

[0051] [Container Execution Platform Control Mechanism Department] The container execution platform control mechanism unit 60 is an interface for operating containers in the Pod 10, and includes a Pod container registration unit 601 and a Pod execution instruction unit 602.

[0052] Based on instructions input by a user, the Pod container registration unit 601 refers to the Pod definition file fp and instructs the container engine 50 to register the Pod 10 and the container. For example, based on the contents of the Pod definition file fp, the Pod container registration unit 601 causes the container engine 50 to create configuration information 502 so that both the application container 1 and the Pod management container 2 are included in the same Pod 10.

[0053] The Pod execution instruction unit 602 instructs the container engine 50 to start the Pod 10 and the application container 1, based on instructions from the user.

[0054] <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 Figure 2. Figure 2 is a block diagram showing an example of the hardware configuration of the control server 100. The calculator 200 shown in Figure 2 is hardware used as a computer.

[0055] 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.

[0056] The control unit 210 includes a central processing unit (CPU) 211, a read only memory (ROM) 212, and a random access memory (RAM) 213.

[0057] 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.

[0058] 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.

[0059] 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, or a nonvolatile memory card. 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.

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

[0061] 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.

[0062] 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.

[0063] <Example of application startup order in the application startup monitoring definition file> Next, an example of setting the application startup order in the application startup monitoring definition file fc will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of a display of a setting screen Sc1 on which the application startup order in the application startup monitoring definition file fc is set. In this embodiment, various setting files such as the application startup monitoring definition file fc are written in, for example, YAML (YAML Ain't Markup Language) format.

[0064] The top row of the setting screen Sc1 shown in Figure 3 states "kind: Appman." This indicates that the type of the item to be set is "Appman" (application management mechanism unit 12). "spec" is a command indicating the description of the setting, and the startup order of the applications is set in the following "tasks." Task indicates the process (task) of the application to be executed within the application container 1.

[0065] "tid" is the ID (identifier) ​​of a task executed as an application. In the example shown in FIG. 3, the setting screen Sc1 instructs that the applications identified by "task1" and "task2" be launched in that order. By making such a setting in the application launch monitoring definition file fc, it is guaranteed that the launch of the task2 application will be performed after the launch of the task1 application has completed.

[0066] "Command" is a command that indicates the description of the setting definition, and in the example shown in Fig. 3, the definitions of the settings "type" and "execStart" are described on the setting screen Sc1. "Type" indicates the type of application, and "execStart" specifies the execution command for starting the application.

[0067] The "oneshot" application type is set for applications that are executed only when the container is started and are not made resident. In a "oneshot" type application, the process that is managed by the application management mechanism unit 12 is an entry point process. The application execution unit 121 of the application management mechanism unit 12 determines that the startup of the application is complete when the entry point process related to the application ends.

[0068] "Simple" is a type set for applications that do not require strict startup synchronization with other tasks. In "simple" type applications, the process that is managed by the application management mechanism 12 is also an entry point process. The application monitoring unit 122 of the application management mechanism 12 determines that the startup of the application is complete when the creation of the entry point process for the application is complete.

[0069] In this embodiment, the application execution unit 121 of the application management mechanism unit 12 starts each application in the application container 1 in the order of application startup defined in the application startup monitoring definition file fc. At this time, the application execution unit 121 determines whether the startup of an application is complete according to the type of application defined in the application startup monitoring definition file fc. Then, after determining that the startup of the started application is complete, the application execution unit 121 starts the next application.

[0070] In other words, according to this embodiment, the subsequent application is launched at the timing when the application preceding it in the launch order transitions to the launch completion state. Therefore, according to this embodiment, application developers can save the effort of creating application launch waiting processes, etc.

[0071] In addition to the examples shown in Figure 3, there are other application types such as "forking." "Forking" is a type 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 splits the parent process into two processes with the same content.

[0072] In a "forking" type application, the process to be managed by the application management mechanism 12 is a child process of the entry point process, i.e., a grandchild process. The application monitoring unit 122 of the application management mechanism 12 determines that the startup of the application is complete when the entry point process related to the application is terminated. In other words, a grandchild process started with forking specified is also managed by the application management mechanism 12. Note that the type of application is not limited to the above example.

[0073] <Example of FB policy settings in the application launch monitoring definition file> Next, an example of setting an FB policy in the application launch monitoring definition file fc will be described with reference to Fig. 4. Fig. 4 is a diagram showing an example of a display of a setting screen Sc2 on which the FB policy in the application launch monitoring definition file fc is set.

[0074] In the setting screen Sc2 shown in Figure 4, for the application with task ID "task3", the "command" item is set followed by the "fallback" item. The "fallback" item describes the FB policy. In the setting screen Sc2, the settings for the "level" and "restartPolicy" items are described within the "fallback" item.

[0075] The "level" item is where the fallback level is set. In the example shown in FIG. 4, a level of "critical" is set for the application with the task ID "task3." When an application with a level of "critical" set is stopped, the application monitoring unit 122 (see FIG. 1) of the application management mechanism unit 12 stops all other applications running in the application container 1. After all other applications are stopped, the application container 1 transitions to a stopped state.

[0076] Other fallback levels include "normal." If an abnormality occurs in an application for which the "normal" level is set, the application monitoring unit 122 of the application management mechanism unit 12 stops only that application and allows other applications to continue to operate. By performing such control by the application monitoring unit 122 of the application management mechanism unit 12, operation continues in the application container 1 while some applications are stopped. In other words, container operation continues in the application container 1 in a degraded function state.

[0077] In the "restartPolicy" item, the restart policy is set. In the example shown in FIG. 4, the following settings are described as the restart policy for the application with the task ID "task3".

[0078] restart: on-success startLimitIntervalSec: 10 startLimitBurst: 5 restartSec: 1000

[0079] In the "restart" item, the restart trigger condition is set. In the restart trigger condition, information on whether to restart the application with respect to the termination cause of the application is set. In the "startLimitIntervalSec" item, the elapsed time required to reset the number of restarts since the last restart of the application is set. In the "startLimitBurst" item, the upper limit number of restarts of the application is set. The restart of the application is performed within the time set in the "startLimitIntervalSec" item until the number specified in the "startLimitBurst" item is reached. In the "restartSec" item, the interval time for restarting the application is set.

[0080] In this embodiment, the application monitoring unit 122 of the application management mechanism unit 12 performs handling according to the FB policy set for each application. Therefore, by appropriately defining the FB policy for each application in the application startup monitoring definition file fc by the user, handling at the time of abnormality occurrence can be appropriately performed. Note that the items of the FB policy set in the application startup monitoring definition file fc are not limited to the example shown in FIG. 4.

[0081] <Example of Pod definition file settings> Next, a setting example of the Pod definition file fp will be described with reference to Fig. 5. Fig. 5 is a diagram showing a display example of the setting screen Sc3 on which the Pod definition file fp is set.

[0082] The "apiVersion" field at the top of the settings screen Sc3 is where information about the version of the API (Application Programming Interface) schema is set. The following "kind" field is where information about the type of item to be set is set. In the settings screen Sc3 shown in Figure 5, the Pod definition file fp is set, so "Pod" is specified in the "kind" field.

[0083] The "metadata" field contains information to identify Pod 10. The "name" field contains the name of Pod 10, and the "version" field contains the version information of Pod 10.

[0084] The following "spec" item sets configuration items that are common to all containers in Pod10. The "resource" item sets information about the machine resources to be allocated to Pod10. The "limits" item sets resource limit values. In the example shown in Figure 5, the "cpuset" item is set in the "limits" item. The "cpuset" item specifies the CPU cores to be allocated to Pod10. In the example shown in Figure 5, "cpus:"0-1"" is written. This description instructs Pod10 to be assigned CPU core numbers "0-1".

[0085] The "stopOnContainerFailure" item specifies whether or not other containers in Pod10 should be stopped and Pod10 should be stopped if any container in Pod10 stops. If "true" is set, other containers in Pod10 will also be stopped and Pod10 will be stopped if any container in Pod10 stops. On the other hand, if "false" is set, other containers in Pod10 will continue to operate.

[0086] Other items that specify the start or stop behavior of Pod10 include "startingDeadline Seconds," "stoppingDeadline Seconds," "startingContainer DeadlineSeconds," and "stoppingContainer DeadlineSeconds." The "startingDeadline Seconds" item sets the start timeout time for Pod10. The "stoppingDeadline Seconds" item sets the stop timeout time for Pod10. The "startingContainer DeadlineSeconds" item sets the start timeout time for each container when Pod10 is started. The "stoppingContainer DeadlineSeconds" item sets the stop timeout time for each container when Pod10 is stopped.

[0087] If a Pod startup timeout or container startup timeout set in each of the above items occurs, the intra-pod container monitoring unit 21 stops containers that are in the process of starting or that have already started by performing a forced stop process. At this time, the intra-pod container monitoring unit 21 forcibly stops an application running in the container by sending a signal to the application. Also, if a Pod stop timeout or container stop timeout occurs, the intra-pod container monitoring unit 21 forcibly stops a container that is in the process of stopping. Thereafter, the intra-pod container monitoring unit 21 stops containers that are running in the subsequent Pod 10 by performing a forced stop process.

[0088] The following "containers" item sets information about the containers to be included in Pod10. The "image" item sets information about the container image 11 used by the container, and the "name" item sets the name of the container. The "volumesFrom" item sets the name of the database used by the container. Note that the items set in the Pod definition file fp are not limited to the example shown in Figure 5.

[0089] <Example of event handling rule settings> Next, a setting example of the event handling rule Rc referenced by the system event management unit 202 of the microservice execution management infrastructure unit 20 will be described with reference to Fig. 6. Fig. 6 is a diagram showing a display example of the setting screen Sc4 on which the event handling rule Rc is set.

[0090] The "apiVersion" item at the top of the settings screen Sc4 is the same as that in the settings screen Sc3 shown in Figure 5, so a description thereof will be omitted. In the following "kind" item, "CEPRule" is specified, which indicates the type of event handling rule Rp.

[0091] The "spec" item that follows is where the "rules" item is set. The "rules" item sets the rules for handling events. The "source" item sets the event source, i.e., information indicating the location where the event occurred. In the example shown in Figure 6, the event source is set to "container."

[0092] The "conditions" item is where you set conditions to narrow down the events that will undergo the processing defined in the rule. In the example shown in Figure 6, the "conditions" item defines three conditions as AND conditions: the event source is "container", the event level is "Error", and the "app_id" in the event body is "x1000".

[0093] Then, the system event management unit 202 performs the action (handling) set in the "actions" field for an event that satisfies all the conditions set in the "conditions" field. In the example shown in Fig. 6, the "actions" field defines the action "haltSystem". "haltSystem" is an action that forcibly stops the OS of the container host.

[0094] Other actions performed in response to events include "powerOFFSystem," "rebootSystem," and "panicSystem." "powerOFFSystem" is an action that forcibly shuts down the container host OS and turns off the power to the control server 100. "rebootSystem" is an action that forcibly shuts down the container host OS and then restarts the OS. "panicSystem" is an action that intentionally causes a kernel panic to forcibly shut down the container host OS. Note that the events set in the event handling rule Rc and the actions performed in response to those events are not limited to the example shown in Figure 6.

[0095] <Virtualization system control method using a control server> Next, a method for controlling a virtualization system by the control server 100 according to this embodiment will be described with reference to FIGS. 7 to 10. FIG. 7 is a flowchart showing an example of the control processing procedure when starting up pods and containers. FIG. 8 is a flowchart showing an example of the control processing procedure by the application management mechanism 12. FIG. 9 is a flowchart showing an example of the control processing procedure by the pod management container 2. FIG. 10 is a flowchart showing an example of the control processing procedure by the microservice execution management infrastructure unit 20.

[0096] [Control process when starting Pods and containers] First, an example of the control process procedure when starting a Pod and a container will be described with reference to Fig. 7. First, the container execution unit 503 (see Fig. 1) of the container engine 50 starts the Pod 10 based on the contents of the configuration information 502 (step S1).

[0097] Next, in conjunction with the startup of Pod 10, Pod management container 2, which is placed as an executable binary on the container host, is mounted (inserted) into Pod 10 and started as an entry process of Pod 10 (step S2). Next, the container execution unit 503 of the container engine 50 starts application container 1 (step S3).

[0098] Next, in conjunction with the startup of the application container 1, the application management mechanism 12 arranged as an executable binary on the container host is mounted in each application container 1 started in step S3. Then, the application management mechanism 12 is started as an entry process of the application container 1 (step S4).

[0099] Next, the application execution unit 121 of the application management mechanism unit 12 starts the applications in the application container 1 according to the start order defined in the application start monitoring definition file fc (step S5). After the processing of step S5, the control processing at the time of start-up of the pods and containers ends.

[0100] [Control processing by the application management mechanism] Next, the control process by the application management mechanism 12 will be described with reference to Fig. 8. First, the application monitoring unit 122 of the application management mechanism 12 determines whether or not the termination of an application has been detected (step S11). If it is determined in step S11 that the termination of the application has not been detected (NO in step S11), the application monitoring unit 122 repeats the determination in step S11.

[0101] On the other hand, if it is determined in step S11 that the termination of the application has been detected (YES in step S11), the application monitoring unit 122 checks the cause of the application termination (step S12). Next, the application monitoring unit 122 determines whether the cause of the application termination is a cause for restart (step S13). Whether the cause of the application termination is a cause for restart is defined in the application launch monitoring definition file fc.

[0102] If it is determined in step S13 that the cause of application termination is not a cause of termination for the application to be restarted (NO in step S13), the application monitoring unit 122 performs handling based on the fallback level defined in the application launch monitoring definition file fc (step S14). In step S14, the application monitoring unit 122 performs an action such as continuing the operation (degenerate operation) of other applications or stopping all applications at once, depending on the characteristics (type) of the application to be stopped.

[0103] On the other hand, if it is determined in step S13 that the cause of termination of the application is a cause of termination that is subject to restart (YES in step S13), the application monitoring unit 122 determines whether the number of restarts within the specified time has exceeded the upper limit of the number of restarts (step S15). If it is determined in step S15 that the upper limit of the number of restarts has been exceeded (YES in step S15), the application monitoring unit 122 performs the process of step S14. That is, handling is performed based on the fallback level.

[0104] On the other hand, if it is determined in step S15 that the upper limit of the number of restarts has not been exceeded (NO in step S15), the application monitoring unit 122 restarts the application based on the restart policy defined in the application start-up monitoring definition file fc (step S16). After processing step S14 or step S16, the application monitoring unit 122 sends an event indicating that the application has terminated to the Pod management container 2 (step S17). After processing step S17, the control processing by the application management mechanism unit 12 ends.

[0105] [Control processing by Pod management container] Next, the control processing by the pod management container 2 will be described with reference to Fig. 9. First, the intra-pod event receiver 22 of the pod management container 2 determines whether or not an event has been received from the application management mechanism 12 of the application container 1 (step S21). If it is determined in step S21 that an event has not been received (NO in step S21), the intra-pod event receiver 22 repeats the determination in step S21.

[0106] On the other hand, if it is determined in step S21 that an event has been received (YES in step S21), the intra-pod event receiver 22 executes handling corresponding to the event based on the information of the application container 1 associated with the event and the FB policy associated with the application container 1 (step S22). The FB policy corresponding to the application container 1 is defined in advance in the pod definition file fp.

[0107] The handling performed by the intra-pod event receiver 22 in step S22 includes, for example, forcibly terminating the application container 1 in which an abnormality has been confirmed, or forcibly terminating other application containers 1 in the pod 10. After the processing of step S22, the control processing by the pod management container 2 ends.

[0108] [Control processing by the microservice execution management infrastructure] Next, the control processing by the microservice execution management infrastructure unit 20 will be described with reference to Fig. 10. First, the Pod monitoring unit 201 of the microservice execution management infrastructure unit 20 determines whether or not an event has been received from the Pod management container 2 (step S31). If it is determined in step S31 that an event has not been received (NO in step S31), the Pod monitoring unit 201 repeats the determination in step S31.

[0109] On the other hand, if it is determined in step S31 that an event has been received (YES in step S31), the Pod monitor 201 transmits information about the event to the system event manager 202. Then, the system event manager 202 executes handling corresponding to the event based on the event handling rule Rc associated with the event (step S32). The handling executed by the system event manager 202 in step S32 includes, for example, stopping the container host OS by causing a kernel panic.

[0110] The handling performed by the system event manager 202 includes, for example, forcibly stopping the container host OS, powering off the control server 100, restarting the container host OS, etc. After processing step S32, the control processing by the Pod management container 2 ends.

[0111] In the above-described embodiment, the application management mechanism 12 launches multiple applications based on the contents of the application launch monitoring definition file fc, detects the termination of the launched applications, and takes action when an application terminates abnormally. The application management mechanism 12 is mounted on the application container 1 when the application container 1 is launched, and is launched as an entry point process of the application container 1. Therefore, according to this embodiment, the application management mechanism 12 launched as the entry point process of the application container 1 can detect the abnormal termination of an application and take the action defined in the application launch monitoring definition file fc. Therefore, according to this embodiment, in a virtualization system using container-based virtualization technology, it is possible to quickly respond to an abnormality that occurs in an application.

[0112] The control server 100 according to the above-described embodiment also includes a pod management container 2 that monitors multiple application containers 1. The pod management container 2 is mounted on pod 10 when pod 10 starts up, and is started as the entry point process of pod 10. Therefore, according to this embodiment, it is possible to detect not only abnormalities in the applications running in the application container 1, but also abnormalities in the application container 1 itself, and to take action when an abnormality is detected.

[0113] The control server 100 according to the above embodiment also includes a service execution management infrastructure unit 20 that monitors the pod management container 2 and takes action in response to events sent from the pod management container 10. Therefore, this embodiment can also detect abnormalities in the pod management container 2 itself and take action when an abnormality is detected.

[0114] Furthermore, in the above-described embodiment, information about an abnormality in the container host detected by the OS event detection unit 30 is sent by the OS event monitoring unit 40 to the microservice execution management infrastructure unit 20. Then, the system event management unit 202 of the microservice execution management infrastructure unit 20 handles the event received from the OS event monitoring unit 40. Therefore, according to this embodiment, even if an event occurs in the container host that has a ripple effect on the entire Pod 10, for example, the system event management unit 202 handles the event appropriately.

[0115] Furthermore, in the above-described embodiment, an event generated by the application management mechanism 12 and transmitted to the microservice execution management infrastructure 20 via the Pod management container 2 includes event level information indicating the urgency of handling the event. The system event management unit 202 of the microservice execution management infrastructure 20 prioritizes handling events assigned with a high event level. Therefore, according to this embodiment, action can be taken quickly for serious abnormalities that require prompt handling.

[0116] Furthermore, in the above-described embodiment, the application management mechanism 12 is implemented as an executable file on the container host on which the application container 1 is started. That is, the application management mechanism 12 is not written in the container image 11. Therefore, according to this embodiment, even if the application management mechanism 12 is modified, the versions of the multiple application management mechanism 12 included in the Pod 10 can be easily unified simply by modifying the contents of the executable file. That is, according to this embodiment, application developers can save the effort of creating applications that take into account the coexistence of multiple versions.

[0117] In addition, in the above-described embodiment, the Pod management container 2 is also implemented as an executable file on the container host. In other words, the Pod management container 2 is not written to the container image. Therefore, according to this embodiment, even if the Pod management container 2 is modified, the versions of multiple Pod management containers 2 running on the container host can be easily unified simply by modifying the contents of the executable file. Therefore, according to this embodiment, application developers can save the effort of creating applications that take into account the coexistence of multiple versions.

[0118] Furthermore, in the above-described embodiment, the application launch monitoring definition file fc defines the launch order of multiple applications. The application execution unit 121 of the application management mechanism unit 12 then launches the applications in order according to the launch order defined in the application launch monitoring definition file fc. Therefore, this embodiment saves application developers the trouble of creating application launch waiting processes.

[0119] The above-described embodiment describes 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.

[0120] Furthermore, 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). [Explanation of symbols]

[0121] 1...Application container, 2...Pod management container, 10...Pod, 11...Container image, 12...Application management mechanism, 20...Microservice execution management infrastructure, 21...Intra-pod container monitoring, 22...Intra-pod event receiving, 30...OS event detection, 40...OS event monitoring, 50...Container engine, 60...Container execution infrastructure control mechanism, 100...Control server, 121...Application execution, 122...Application monitoring, 201...Pod monitoring, 202...Intra-system event management, 501...Pod container management, 502...Configuration information, 503...Container execution, 601...Pod container registration, 602...Pod execution instruction

Claims

1. an application launch monitoring definition file that describes settings related to the launch of multiple applications and actions to be taken when the applications abnormally terminate; an application management mechanism unit that starts a plurality of the applications based on the contents of the application start-up monitoring definition file, detects the termination of the started applications, and takes measures when the applications terminate abnormally; The application management mechanism is mounted in an application container in which the application is executed when the application container is started, and is started as an entry point process of the application container. Virtualization system.

2. A management container that monitors the plurality of application containers is further provided, The management container is mounted to a Pod containing a plurality of the application containers when the Pod is started, and is started as an entry point process of the Pod. The virtualization system of claim 1 .

3. The Pod definition file further includes a definition of a response to be taken when the application container abnormally terminates, The management container takes action when the application container abnormally terminates based on the action content defined in the Pod definition file. The virtualization system of claim 2 .

4. the application management mechanism outputs the abnormal termination of the application as an event to the management container; The management container refers to the Pod definition file based on the content described in the event and takes action when the application container abnormally terminates. The virtualization system of claim 3 .

5. a service execution management infrastructure unit that monitors the management container and handles the event based on the content of the event transmitted from the management container; The management container transfers the event input from the application management mechanism to the service execution management infrastructure. The virtualization system of claim 4 .

6. The application container, the management container, and the Pod further include an event monitoring unit that monitors whether or not an abnormality has occurred in a container host on which the application container, the management container, and the Pod are executed, and outputs the details of the detected abnormality to the service execution management infrastructure unit as the event. The virtualization system of claim 5 .

7. The event includes an identifier of the event, information on the type of the event, and a character string indicating the content of the event. The virtualization system of claim 6 .

8. The event further includes event level information indicating the urgency of a response to the event; The service execution management infrastructure unit prioritizes handling of the event to which a high event level is assigned. The virtualization system of claim 7.

9. The application management mechanism is implemented as an executable file on the container host before being mounted in the application container. The virtualization system of claim 8 .

10. The management container is implemented as an executable file on the container host on which the management container is started before being mounted on the Pod. The virtualization system of claim 9.

11. The settings regarding the launch of the plurality of applications in the application launch monitoring definition file define a launch order of the plurality of applications; The application management mechanism unit starts the plurality of applications in order according to the start order of the plurality of applications defined in the application start monitoring definition file. The virtualization system of claim 10.

12. A control method for a virtualization system including: an application launch monitoring definition file that describes settings related to the launch of a plurality of applications and actions to be taken when the applications abnormally terminate; and an application management mechanism that launches the plurality of applications based on the contents of the application launch monitoring definition file, detects the termination of the launched applications, and takes action when the applications abnormally terminate, The application management mechanism includes a procedure in which the application management mechanism is mounted in an application container in which the application is executed when the application container is started, and is started as an entry point process of the application container. How to control a virtualized system.

Images