Virtualization system and control method for virtualization system

Abstract

A control server where a virtualization system according to one aspect of the present invention is constructed is provided with an application management mechanism unit that starts a plurality of applications on the basis of the written content of an application startup monitoring definition file, and handles abnormal termination of the started applications that has occurred. Further, the application management mechanism unit is mounted in an application container, where the applications are executed, when the application container is started, and is started as an entry point process of the application container.

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] Anomalies (faults) 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 of a worker node by polling, and determines whether the system is normal or abnormal based on the response result returned from the Pod in response to the command.

[0005] WO 2023 / 275985

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

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

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

[0010] FIG. 1 is a block diagram illustrating an example of the functional configuration of a control server according to an embodiment of the present invention. 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. FIG. 3 is a diagram illustrating an example of a display of a settings screen on which an application startup order is set in an application startup monitoring definition file according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an example of a display of a settings screen on which an FB policy is set in an application startup monitoring definition file according to an embodiment of the present invention. FIG. 5 is a diagram illustrating an example of a display of a settings screen on which a Pod definition file is set according to an embodiment of the present invention. FIG. 6 is a diagram illustrating an example of a display of a settings screen on which an event handling rule is set according to an embodiment of the present invention. FIG. 7 is a flowchart illustrating an example of a control processing procedure when a Pod and a container are started according to an embodiment of the present invention. FIG. 8 is a flowchart illustrating an example of a control processing procedure by an application management mechanism unit according to an embodiment of the present invention. FIG. 9 is a flowchart illustrating an example of a control processing procedure by a Pod management container according to an embodiment of the present invention. FIG. 10 is a flowchart illustrating an example of a control processing procedure by a microservice execution management infrastructure unit 20 according to an embodiment of the present 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 launch 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 application containers 1-1 to 1-n, they will be collectively referred to as application container 1.

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

[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. Note that 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 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 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, a fallback (FB) policy to be applied when the termination of an application is detected, and the like. An example of a definition of the application launch order in the application launch monitoring definition file fc will be described in detail below 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 in 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 started as the entry process of the application container 1.

[0022] The setting to set the entry point process of the application container 1 to the application management mechanism unit 12 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 within 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 launched by the application execution unit 121. For example, the application monitoring unit 122 detects the termination of an application 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 monitoring unit 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 application restart policy and fallback level.

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

[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 has been restarted within a specified time period 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 of the restart target 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 handling 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 the present embodiment, detailed information about an event in which an abnormality has been 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 Application Management Mechanism] Here, the reason why the application container 1 according to this embodiment includes the application management mechanism 12 will be explained. In conventional technology, it is 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. In this type of operation, the reliability of the entry point process 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. Furthermore, because specifications may be designed to forcibly shut down the container itself if the entry point process in the container stops, 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 within 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 unit 12 in the container image 11, it is possible to easily unify the versions of multiple application management mechanism units 12 included in the Pod 10. This allows the versions of 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 receiving unit 22 receives an event from the intra-pod container monitoring unit 21, it handles the event based on a preset FB policy for the application container 1 that sent the event. The FB policy for each application container 1 is defined in advance in a pod definition file fp. An example of a user's 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 receiving unit 22 transmits the anomaly detection event as an event to the microservice execution management infrastructure unit 20 .

[0044] 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 and centrally manages events within the control server 100. The microservice execution management infrastructure unit 20 includes a Pod monitoring unit 201 and an in-system event management unit 202.

[0045] The pod monitoring unit 201 outputs information about the event transmitted from the intra-pod event receiving unit 22 of the pod management container 2 to the intra-system event management unit 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 actions (handling) associated with events according to event handling rules 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 below 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 non-volatile storage 220 (see FIG. 2 ) of the control server 100 or a failure related to a network (not shown).

[0048] The OS event monitoring unit 40 (an example of an event monitoring unit) receives OS events detected by the OS event detection unit 30 and outputs them to the system event management unit 202 of the microservice execution management infrastructure unit 20. More specifically, the OS event monitoring unit 40 reconstructs information on failures detected by the OS event detection unit 30 from various targets using various detection methods into information on events that can be managed by the system event management unit 202 and outputs the information to the system event management unit 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 information about the Pod 10 and containers registered by the Pod container registration unit 601 of the container execution platform control mechanism unit 60. The Pod container management unit 501 also changes the contents of the configuration information 502 based on change information about the Pod 10 and / or container configurations input from the Pod container registration unit 601.

[0050] The configuration information 502 is a file that describes information about the configurations of the Pod 10, the application container 1, and the Pod container 2, and information such as the storage location of the container image 11. The container execution unit 503, in accordance with an instruction from the Pod execution instruction unit 602 of the container execution platform control mechanism unit 60, references the information described in the configuration information 502 and starts the application container 1 and the Pod management container 2.

[0051] [Container Execution Platform Control Mechanism] The container execution platform control mechanism 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 the user, the Pod container registration unit 601 references 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 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.

[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 CPU (Central Processing Unit) 211 , a ROM (Read Only Memory) 212 , and a RAM (Random Access Memory) 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, 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.

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

[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 Setting Application Startup Order in Application Activation 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 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 Int 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" are to be launched in this 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 processes that are managed by the application management mechanism 12 are also entry point processes. 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 application startup order 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 application type 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 example 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 a 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 ends. In other words, a grandchild process started with forking specified is also managed by the application management mechanism 12. Note that the application type is not limited to the example described above.

[0073] <Setting Example of FB Policy in Application Activation Monitoring Definition File> Next, a setting example of the FB policy in the application activation monitoring definition file fc will be described with reference to Fig. 4. Fig. 4 is a diagram showing a display example of a setting screen Sc2 on which the FB policy in the application activation monitoring definition file fc is set.

[0074] In the setting screen Sc2 shown in FIG. 4, for an application with a task ID of "task3," the "command" field is followed by the "fallback" field. The "fallback" field describes the FB policy. In the setting screen Sc2, the settings for the "level" and "restartPolicy" fields are described within the "fallback" field.

[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] The restart policy is set in the "restartPolicy" item. In the example shown in Fig. 4, the following setting is written as the restart policy for the application with task ID "task3".

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

[0079] The "restart" item is where the restart trigger condition is set. In the restart trigger condition, information on whether or not the application needs to be restarted in response to the cause of the application termination is set. The "startLimitIntervalSec" item is where the elapsed time required from the last time the application was restarted until the restart count is reset is set. The "startLimitBurst" item is where the upper limit for the number of restarts of the application is set. The application is restarted within the time set in the "startLimitIntervalSec" item until the number of restarts set in the "startLimitBurst" item is reached. The "restartSec" item is where the interval time between restarts of the application is set.

[0080] In this embodiment, the application monitoring unit 122 of the application management mechanism unit 12 handles each application according to the FB policy set for that application. Therefore, if the user appropriately defines the FB policy for each application in the application launch monitoring definition file fc, handling of an abnormality when it occurs can be performed appropriately. Note that the items of the FB policy set in the application launch monitoring definition file fc are not limited to the example shown in FIG. 4.

[0081] <Pod Definition File Setting Example> 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 setting 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 the item to be set is set. Since the setting screen Sc3 shown in FIG. 5 is where the Pod definition file fp is set, "Pod" is specified in the "kind" field.

[0083] The "metadata" field contains information for identifying the Pod 10. The "name" field contains the name of the Pod 10, and the "version" field contains information about the version of the Pod 10.

[0084] In the following "spec" item, setting items common to all containers in Pod 10 are set. In the "resource" item, information about the machine resources to be allocated to Pod 10 is set. In the "limits" item, resource limit values ​​are set. In the example shown in FIG. 5, the "cpuset" item is set in the "limits" item. In the "cpuset" item, the CPU core to be allocated to Pod 10 is specified. In the example shown in FIG. 5, "cpus: "0-1"" is written. This description instructs that CPU core numbers "0-1" be assigned to Pod 10.

[0085] The "stopOnContainerFailure" item sets information on whether or not, when any container in Pod 10 stops, other containers included in Pod 10 are also stopped and Pod 10 is put into a stopped state. When "true" is set, when any container in Pod 10 stops, the other containers included in Pod 10 are also stopped and Pod 10 is stopped. On the other hand, when "false" is set, the operation of the other containers in Pod 10 continues.

[0086] Other items that define the startup or shutdown behavior of the Pod 10 include "startingDeadline Seconds," "stoppingDeadline Seconds," "startingContainer DeadlineSeconds," and "stoppingContainer DeadlineSeconds." The "startingDeadline Seconds" item sets the startup timeout time for the Pod 10. The "stoppingDeadline Seconds" item sets the shutdown timeout time for the Pod 10. The "startingContainer DeadlineSeconds" item sets the startup timeout time for each container when the Pod 10 is started. The "stoppingContainer DeadlineSeconds" item sets the shutdown timeout time for each container when the Pod 10 is stopped.

[0087] When a Pod startup timeout or a 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 up 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. Furthermore, when a Pod stop timeout or a 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 running containers in the subsequent Pod 10 by performing a forced stop process.

[0088] In the subsequent "containers" item, information about the containers to be included in the Pod 10 is set. In the "image" item, information about the container image 11 used by the container is set, and in the "name" item, the name of the container is set. In the "volumesFrom" item, the name of the database used by the container is set. Note that the items set in the Pod definition file fp are not limited to the example shown in FIG. 5.

[0089] <Example of Setting Event Handling Rules> Next, a setting example of the event handling rules Rc referenced by the intra-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 rules Rc are set.

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

[0091] In the following "spec" item, the "rules" item is set. In the "rules" item, rules for handling an event are set. In the "source" item, the event source, i.e., information indicating the location where the event occurred, is set. In the example shown in FIG. 6, "container", i.e., a container, is set as the event source.

[0092] In the "conditions" field, conditions are set to narrow down the events that are the targets of the processing defined in the rule. In the example shown in Fig. 6, three conditions are defined as AND conditions in the "conditions" field: 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" item for an event that satisfies all the conditions set in the "conditions" item. In the example shown in Fig. 6, the "actions" item 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 FIG. 6.

[0095] <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 FIGS. 7 to 10. FIG. 7 is a flowchart showing an example of the control processing procedure when Pods and containers are started. 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 Processing at the Startup of Pods and Containers] First, an example of the procedure of the control processing at the startup of Pods and containers will be described with reference to Fig. 7. First, the container execution unit 503 of the container engine 50 (see Fig. 1) starts the Pod 10 based on the contents of the configuration information 502 (step S1).

[0097] Next, in conjunction with the startup of the Pod 10, the Pod management container 2 arranged as an execution binary on the container host is mounted (inserted) into the Pod 10 and started as an entry process of the Pod 10 (step S2). Next, the container execution unit 503 of the container engine 50 starts the 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 in accordance with the start-up order defined in the application start-up monitoring definition file fc (step S5). After the processing of step S5, the control processing at the time of start-up of the Pod and the container is completed.

[0100] [Control Processing by Application Management Mechanism] Next, the control processing 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 termination of an application has been detected (step S11). If it is determined in step S11 that termination of an 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 the application termination is not a cause of the application to be restarted (NO in step S13), the application monitoring unit 122 handles the application based on the fallback level defined in the application startup monitoring definition file fc (step S14). In step S14, the application monitoring unit 122 performs an action such as continuing the operation of other applications (degenerate operation) 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 the application termination is a cause of termination for the application to be restarted (YES in step S13), the application monitor 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 monitor 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 monitor 122 restarts the application based on the restart policy defined in the application startup monitoring definition file fc (step S16). After processing step S14 or step S16, the application monitor 122 sends an event indicating that the application has terminated to the Pod management container 2 (step S17). After processing step S17, the control process by the application management mechanism 12 ends.

[0105] 9, the control process by the Pod management container 2 will be described. First, the intra-Pod event receiving unit 22 of the Pod management container 2 determines whether or not an event has been received from the application management mechanism unit 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 receiving unit 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 receiving unit 22 executes handling corresponding to the event (step S22) based on the information of the application container 1 associated with the event and the FB policy associated with the application container 1. The FB policy associated with the application container 1 is defined in advance in the Pod definition file fp.

[0107] The handling performed by the intra-pod event receiving unit 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 Microservice Execution Management Infrastructure Unit] 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 monitoring unit 201 transmits information about the event to the system event management unit 202. Then, the system event management unit 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 management unit 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 step S32 is completed, 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, a virtualization system using container-based virtualization technology can quickly respond to an abnormality that occurs in an application.

[0112] The control server 100 according to the above embodiment also includes a Pod management container 2 that monitors multiple application containers 1. The Pod management container 2 is mounted on the Pod 10 when the Pod 10 starts up, and is started as the entry point process for the Pod 10. Therefore, this embodiment can detect not only abnormalities in the applications running in the application container 1, but also abnormalities in the application container 1 itself, and 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 transmitted 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 the present 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 important 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] Furthermore, in the above-described embodiment, the Pod management container 2 is also implemented as an executable file on the container host. That is, 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 startup monitoring definition file fc defines the startup order of multiple applications. The application execution unit 121 of the application management mechanism unit 12 then starts the applications in order according to the startup order defined in the application startup monitoring definition file fc. Therefore, this embodiment saves application developers the trouble of creating application startup 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] 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).

[0121] DESCRIPTION OF SYMBOLS 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. A virtualization system comprising: an application launch monitoring definition file that contains settings for launching multiple applications and the measures to be taken when the applications abnormally terminate; and an application management mechanism that launches the multiple applications based on the contents of the application launch monitoring definition file, detects the termination of the launched applications, and takes measures when the applications abnormally terminate, wherein the application management mechanism is mounted to an application container in which the applications are executed when the application container is launched, and is launched as an entry point process of the application container.

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

3. The virtualization system of claim 2, further comprising a Pod definition file that defines the measures to be taken when the application container abnormally terminates, and the management container takes measures when the application container abnormally terminates based on the measures defined in the Pod definition file.

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

5. The virtualization system of claim 4, further comprising a service execution management infrastructure unit that monitors the management container and takes action against the event based on the content described in the event sent from the management container, and the management container transfers the event input from the application management mechanism unit to the service execution management infrastructure unit.

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

7. The virtualization system according to claim 6, wherein 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.

8. The virtualization system described in claim 7, wherein the event further includes event level information indicating the urgency of dealing with the event, and the service execution management infrastructure unit gives priority to dealing with events assigned a high event level.

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

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

11. The virtualization system described in claim 10, wherein the settings regarding the startup of the multiple applications in the application startup monitoring definition file specify the startup order of the multiple applications, and the application management mechanism unit starts the multiple applications in sequence in accordance with the startup order of the multiple applications specified in the application startup monitoring definition file.

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

Images