WO2025197136A1 - 仮想化システム及び仮想化システムの制御方法 - Google Patents

仮想化システム及び仮想化システムの制御方法

Info

Publication number
WO2025197136A1
WO2025197136A1 PCT/JP2024/026971 JP2024026971W WO2025197136A1 WO 2025197136 A1 WO2025197136 A1 WO 2025197136A1 JP 2024026971 W JP2024026971 W JP 2024026971W WO 2025197136 A1 WO2025197136 A1 WO 2025197136A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
container
event
pod
management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/026971
Other languages
English (en)
French (fr)
Inventor
達矢 小野
雅昭 小川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of WO2025197136A1 publication Critical patent/WO2025197136A1/ja
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance

Definitions

  • the present invention relates to a virtualization system and a method for controlling a virtualization system.
  • microservices architecture has become popular. Rather than realizing complex requirements with a single (monolithic) application, systems are created by combining independent "microservices” that each provide a small function. By adopting a microservices 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 microservices architecture also makes it possible to gradually expand a system.
  • Microservice architecture can be realized, for example, using container-based virtualization technology.
  • Containers are independent spaces created on the host OS (Operating System) using virtualization technology, making it possible to create an execution environment for each application managed as a "microservice" in each independent space.
  • OS Operating System
  • 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 specified command to the Pod of the 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.
  • Patent Document 1 does not describe any anomaly detection methods other than polling.
  • the present invention was made in consideration of the above situation, and its purpose is to enable rapid response to abnormalities that occur in applications in a virtualization system that uses container-based virtualization technology.
  • a virtualization system comprises an application launch monitoring definition file that contains settings related to the launch of multiple applications and the 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 the application container in which the application is executed when the application container is launched, and is launched as the entry point process of the application container.
  • 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.
  • Pod 10 is the smallest unit that controls the launch of applications, and is composed of one or more containers.
  • 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.
  • application container 1 when it is not necessary to individually identify application containers 1-1 to 1-n, they will be collectively referred to as application container 1.
  • the containers contained within a Pod 10 share various resources and networks (not shown). 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.
  • 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.
  • 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.
  • OS operating system
  • 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.
  • 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 starts an application based on the contents of the application start-up monitoring definition file fc.
  • the setting to set 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.
  • 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.
  • 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 receiving 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 Linux (registered trademark) prctl (PR_SET_CHILD_SUBREAPER) function. Note that the method for managing child, grandchild, and great-grandchild processes is not limited to this example, and other methods may be used.
  • the application monitoring unit 122 When the application monitoring unit 122 detects that an application has terminated, it checks the cause of the application's termination and handles the termination accordingly.
  • the handling details corresponding to the termination cause are specified as an FB policy in the application launch monitoring definition file fc.
  • the FB policy includes, for example, information about the application's restart policy and fallback level.
  • the "restart policy” sets the conditions and timing for restarting an application when it is terminated.
  • the “fallback level” sets the policy for continuing operation of other applications running within the same application container 1 when the terminated application is not restarted and the target application is put into a stopped state.
  • the application monitoring unit 122 detects an abnormal application termination if the cause of the application termination is other than the termination cause of the target restart, or if the number of times the application is restarted within a specified time period exceeds the upper limit. Then, in response to the detection of an abnormal termination, the application monitoring unit 122 performs an action (handling) defined as a fallback level. Examples of actions defined as fallback levels include restarting the application and forcibly stopping the application container 1.
  • the application monitoring unit 122 restarts the application based on the restart policy.
  • an event is composed of, for example, an event ID as an identifier, a string (message) describing the event, and a body that describes additional information about the event.
  • the event ID is composed of an event identifier, information indicating the type of event, and information indicating the event level.
  • the event level is information that indicates the urgency of dealing with the event, and includes, for example, "Critical,” “Error,” “Warning,” “Notice,” and “Info.”
  • “Critical” is the level set for events that indicate serious errors that require some kind of immediate action
  • "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.
  • the reason why the application container 1 according to this embodiment includes the application management mechanism unit 12 will be explained.
  • it is common to run one application in one container and start and link multiple containers to configure a system.
  • 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.
  • 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. This control by the application execution unit 121 improves the reliability of the execution of the entry point processes of the application containers 1.
  • the application management mechanism unit 12 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 then dynamically mounted (inserted) into the application container 1 when the application container 1 is started, and is started as the entry process of the application container 1.
  • 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.
  • 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 sent 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.
  • the intra-pod event receiving unit 22 When the intra-pod event receiving unit 22 receives an event from the intra-pod container monitoring unit 21, it handles the event according to the FB policy preset for the application container 1 that sent the event.
  • the FB policy for each application container 1 is predefined in the pod definition file fp.
  • An example of a user-defined pod definition file fp will be described in detail below with reference to Figure 5.
  • 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 within the Pod 10.
  • the intra-pod event receiver 22 controls abnormality handling on an application container 1 or Pod 10 basis. Note that the intra-pod event receiver 22 does not analyze the contents of applications, but it does manage the status of the application container 1 or Pod 10, and record and store detailed information such as error logs.
  • the intra-pod event receiving unit 22 transmits the anomaly detection event as an event to the microservice execution management infrastructure unit 20.
  • 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 in 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.
  • the pod monitoring unit 201 outputs event information sent from the pod event receiving unit 22 of the pod management container 2 to the system event management unit 202.
  • 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 configuration information 502 based on information about the Pod 10 and the container 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 content of the configuration information 502 based on change information about the Pod 10 and/or the container configuration input from the Pod container registration unit 601.
  • the computer 200 includes a control unit 210, non-volatile storage 220, display unit 230, operation input unit 240, and communication I/F (Interface) 250, each of which is connected to bus B.
  • the CPU 211 reads the program code of the software that realizes each function of this embodiment from the ROM 212, expands it into the RAM 213, and executes it. Variables, parameters, etc. that arise during the calculation process are temporarily written to the RAM 213.
  • control unit 210 may be equipped with a processing device such as an MPU (Micro-Processing Unit) instead of the CPU 211.
  • control unit 210 may use both a CPU and an MPU.
  • the non-volatile 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 non-volatile memory card.
  • This non-volatile storage 220 stores the OS, various parameters, and programs for running the computer 200. The programs may also be stored in the ROM 212.
  • 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 in response to an operation by a user and supplies the operation signal to the CPU 211 .
  • the display unit 230 and the operation input unit 240 may be integrated into a single unit as a touch panel.
  • the program is stored in the form of computer-readable program code, and the CPU 211 sequentially executes operations in accordance with the program code.
  • the ROM 212 or 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.
  • the communication I/F 250 may use, for example, a Network Interface Card (NIC), and can transmit and receive various types of data to and from external devices via a network or communication line.
  • NIC Network Interface Card
  • 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.
  • various setting files such as the application startup monitoring definition file fc are written in, for example, YAML (YAML Int Markup Language) format.
  • the top row of the settings screen Sc1 shown in Figure 3 states "kind: Appman.” This indicates that the type of item being set is “Appman” (application management mechanism unit 12). "spec” is a command that describes the setting, and the startup order of the applications is set in the following "tasks.” Task indicates the application process (task) to be executed within the application container 1.
  • “tid” is the ID (identifier) of the task to be executed as an application.
  • the settings screen Sc1 instructs that the applications identified by "task1" and "task2" be launched in that order.
  • the application launch monitoring definition file fc it is guaranteed that the task2 application will be launched after the task1 application has completed launching.
  • “Command” is a command that describes the definition of a setting.
  • the definitions of the settings "type” and “execStart” are described on the settings screen Sc1.
  • “Type” indicates the type of application, and "execStart” specifies the execution command for starting the application.
  • the “oneshot” application type is set for applications that are executed only when the container is started and are not made resident.
  • the process that is managed by the application management mechanism unit 12 is the entry point process.
  • the application execution unit 121 of the application management mechanism unit 12 determines that the startup of the application has been completed when the entry point process related to the application terminates.
  • “Simple” is a type set for applications that do not require strict startup synchronization with other tasks.
  • 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.
  • the application execution unit 121 of the application management mechanism unit 12 launches each application in the application container 1 in the application launch order defined in the application launch monitoring definition file fc. At this time, the application execution unit 121 determines whether the application has launched properly according to the application type defined in the application launch monitoring definition file fc. Then, after determining that the launched application has launched properly, the application execution unit 121 launches the next application.
  • the subsequent application is launched when the application preceding it in the launch order transitions to the launch completion state. Therefore, this embodiment saves application developers the trouble of creating application launch waiting processes, etc.
  • the application type may be "forking” or the like.
  • "Forking” is a type that is set for applications with a program structure that forks after the application's 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.
  • the process that is managed by the application management mechanism unit 12 is the child process of the entry point process, i.e., the grandchild process.
  • the application monitoring unit 122 of the application management mechanism unit 12 determines that the startup of the application has been completed when the entry point process related to the application has terminated.
  • grandchild processes that are started with forking specified are also managed by the application management mechanism unit 12. Note that application types are not limited to the examples mentioned above.
  • 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.
  • the "level” item is where the fallback level is set.
  • a level of “critical” is set for the application with task ID "task3". If an application with a level of "critical” set is stopped, the application monitoring unit 122 (see Figure 1) of the application management mechanism unit 12 stops all other applications running within application container 1. Then, after all other applications have stopped, application container 1 transitions to a stopped state.
  • 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 will stop only that application, while allowing other applications to continue operating. This control by the application monitoring unit 122 of the application management mechanism unit 12 allows the application container 1 to continue operating while some applications are stopped. In other words, the application container 1 continues operating in a degraded functional state.
  • restart on-success startLimitIntervalSec: 10 startLimitBurst: 5 restartSec: 1000
  • the "restart” item sets the restart trigger conditions.
  • the restart trigger conditions set information about whether or not an application needs to be restarted in response to an application termination cause.
  • the "startLimitIntervalSec” item sets the elapsed time required from the last time the application was restarted until the restart count is reset.
  • the “startLimitBurst” item sets the upper limit on the number of times the application can be restarted. The application will be restarted within the time set in the "startLimitIntervalSec” item, until the number of times set in the "startLimitBurst” item is reached.
  • the “restartSec” item sets the interval time between application restarts.
  • 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 will be carried out appropriately when an abnormality occurs.
  • the FB policy items set in the application launch monitoring definition file fc are not limited to the example shown in Figure 4.
  • FIG. 5 is a diagram showing a display example of the setting screen Sc3 on which the Pod definition file fp is set.
  • the "apiVersion” item 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” item is where information about the type of item being set is set.
  • the Pod definition file fp is set, so "Pod” is specified in the "kind” item.
  • the "metadata” field information for identifying the Pod10 is set.
  • the name of the Pod10 is set, and in the "version” field, information about the version of the Pod10 is set.
  • the following "spec” section sets configuration items common to all containers in Pod10.
  • the “resource” section sets information about the machine resources to be allocated to Pod10.
  • the “limits” section sets resource limits. In the example shown in Figure 5, the “cpuset” section is set in the “limits” section.
  • the “cpuset” section specifies the CPU core to be allocated to Pod10. In the example shown in Figure 5, “cpus: "0-1”" is written. This statement instructs Pod10 to be assigned CPU core numbers "0-1”.
  • the "stopOnContainerFailure” item sets information about whether or not other containers in Pod10 should be stopped and Pod10 should be put into a stopped state when any container in Pod10 stops. If “true” is set, when any container in Pod10 stops, the other containers in Pod10 will also be stopped and Pod10 will be stopped. On the other hand, if “false” is set, the operation of other containers in Pod10 will continue.
  • startingDeadline Seconds sets the startup timeout time for Pod10.
  • stoppingDeadline Seconds sets the stopping timeout time for Pod10.
  • startingContainer DeadlineSeconds sets the startup timeout time for each container when Pod10 is started.
  • stoppingContainer DeadlineSeconds sets the stopping timeout time for each container when Pod10 is stopped.
  • the 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 Pod container monitoring unit 21 forcibly stops an application running in the container by sending a signal to the application. Furthermore, if a Pod stop timeout or container stop timeout occurs, the Pod container monitoring unit 21 forcibly stops a container that is in the process of stopping. Thereafter, the Pod container monitoring unit 21 stops running containers in the subsequent Pod 10 by performing a forced stop process.
  • the system event management unit 202 performs the action (handling) set in the "actions" field for events that satisfy all of the conditions set in the "conditions” field.
  • the "haltSystem” action is defined in the “actions” field.
  • "haltSystem” is an action that forcibly stops the OS of the container host.
  • 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 performed by the application management mechanism 12.
  • FIG. 9 is a flowchart showing an example of the control processing procedure performed by the Pod management container 2.
  • FIG. 10 is a flowchart showing an example of the control processing procedure performed by the microservice execution management infrastructure unit 20.
  • Pod management container 2 which is located as an executable binary on the container host, is mounted (inserted) into Pod 10 and started as the entry process of Pod 10 (step S2).
  • the container execution unit 503 of the container engine 50 starts application container 1 (step S3).
  • the application management mechanism 12 which is located as an executable binary on the container host, is mounted within each application container 1 started in step S3.
  • the application management mechanism 12 is then started as the entry process of the application container 1 (step S4).
  • step S5 the application execution unit 121 of the application management mechanism unit 12 launches applications within the application container 1 in accordance with the launch order defined in the application launch monitoring definition file fc (step S5).
  • step S5 the control process for launching the Pod and container ends.
  • step S11 determines whether or not termination of an application has been detected. 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.
  • step S11 determines whether the termination of the application has been detected (YES in step S11). Then, the application monitoring unit 122 determines whether the cause of the application termination is a termination cause for the application to be restarted (step S13). Whether or not the cause of application termination is subject to restart is defined in the application launch monitoring definition file fc.
  • step S13 If it is determined in step S13 that the cause of the application termination is not a cause for the application to be restarted (step S13: NO), the application monitoring unit 122 handles the termination based on the fallback level defined in the application startup monitoring definition file fc (step S14). In step S14, the application monitoring unit 122 takes 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 that is being stopped.
  • step S13 determines whether the cause of application termination is a cause for termination of the application to be restarted. If it is determined in step S15 that the cause of application termination is a cause for termination of the application to be restarted (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 processing of step S14. In other words, handling is performed based on the fallback level.
  • step S15 if it is determined in step S15 that the upper limit of the number of restarts has not been exceeded (step S15 is NO), the application monitoring unit 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 monitoring unit 122 sends an event indicating the application termination to the Pod management container 2 (step S17). After processing step S17, the control processing by the application management mechanism unit 12 ends.
  • Step S21 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.
  • step S21 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 based on the information about the application container 1 associated with the event and the FB policy associated with the application container 1 (step S22).
  • the FB policy associated with the application container 1 is predefined in the pod definition file fp.
  • 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.
  • the control processing by the Pod management container 2 ends.
  • Step S31 the Pod monitoring unit 201 of the microservice execution management infrastructure unit 20 determines whether 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.
  • step S31 if it is determined in step S31 that an event has been received (YES in step S31), the pod monitoring unit 201 sends event information to the system event management unit 202.
  • the system event management unit 202 then performs handling corresponding to the event based on the event handling rule Rc associated with the event (step S32). Handling performed by the system event management unit 202 in step S32 includes, for example, stopping the container host OS by causing a kernel panic.
  • Handling performed by the system event management unit 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.
  • 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 the 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.
  • control server 100 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 of the Pod 10. Therefore, according to this embodiment, it is possible to detect not only abnormalities in the applications running within the application container 1, but also abnormalities in the application container 1 itself, and to take action when an abnormality is detected.
  • the control server 100 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, according to this embodiment, it is possible to detect abnormalities in the Pod management container 2 itself and take action when an abnormality is detected.
  • 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.
  • the system event management unit 202 of the microservice execution management infrastructure unit 20 then 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 will handle the event appropriately.
  • events generated by the application management mechanism unit 12 and sent to the microservice execution management infrastructure unit 20 via the Pod management container 2 include event level information indicating the urgency of handling the event.
  • the system event management unit 202 of the microservice execution management infrastructure unit 20 then prioritizes handling events assigned a high event level. Therefore, according to this embodiment, action can be taken quickly in response to serious abnormalities that require prompt handling.
  • the application management mechanism unit 12 is implemented as an executable file on the container host on which the application container 1 is started. In other words, the application management mechanism unit 12 is not written to the container image 11. Therefore, according to this embodiment, even if the application management mechanism unit 12 is modified, the versions of multiple application management mechanism units 12 included in the Pod 10 can be easily unified simply by modifying the contents of the executable file. In other words, this embodiment saves application developers the trouble of creating applications that take into account the coexistence of multiple versions.
  • 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, it is easy to unify the versions of multiple Pod management containers 2 running on the container host simply by modifying the contents of the executable file. Therefore, this embodiment saves application developers the trouble of creating applications that take into account the coexistence of multiple versions.
  • 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 of multiple applications defined in the application launch monitoring definition file fc. Therefore, this embodiment saves application developers the trouble of creating application launch waiting processes, etc.
  • control lines or information lines indicated by solid lines or arrows in Figures 1 and 2 indicate those that are considered necessary for explanation, and do not necessarily represent all control lines or information lines in the product. In reality, it can be assumed that almost all components are interconnected.
  • 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

本発明の一態様の仮想化システムが構築される制御サーバーは、アプリ起動監視定義ファイルの記載内容に基づいて複数のアプリケーションを起動させ、起動したアプリケーションの異常終了時における対処を行うアプリケーション管理機構部を備える。そして、アプリケーション管理機構部は、アプリケーションが実行されるアプリケーションコンテナの起動時にアプリケーションコンテナにマウントされ、アプリケーションコンテナのエントリポイントプロセスとして起動される。

Description

仮想化システム及び仮想化システムの制御方法
　本発明は、仮想化システム及び仮想化システムの制御方法に関する。
　近年、複雑な要件を単一の（モノリシックな）アプリケーションで実現するのではなく、小さな機能ごとに独立した「マイクロサービス」の組み合わせによってシステムを実現する「マイクロサービスアーキテクチャ」が普及している。マイクロサービスアーキテクチャを採用することによって、マイクロサービス単位で新規機能の追加や変更が可能となるため、システムへの機能の追加や変更が容易に行えるようになる。したがって、マイクロサービスアーキテクチャを用いることにより、システムを段階的に拡張することも可能となる。
　マイクロサービスアーキテクチャは、例えば、コンテナ型仮想化技術によって実現できる。コンテナは、仮想化技術によってホストＯＳ（Operating System）上に形成される独立した空間であるため、各独立空間において「マイクロサービス」として管理される各アプリケーションの実行環境を構築することができる。
　コンテナを用いて構築されたシステムにおける異常（障害）は、ポーリング等の手法を用いて検知が可能である。例えば、特許文献１には、異常検知部を備えた仮想化システム障害分離装が記載されている。特許文献１に記載の異常検知部は、ポーリングによって所定のコマンドをワーカーノードのＰｏｄに送信し、コマンドに応じてＰｏｄから返信されてくる応答結果により正常か異常かを判断する。
国際公開第２０２３／２７５９８５号
　ところで、コンテナの技術を用いて仮想化されるシステムが、例えば産業インフラストラクチャ等における制御システムである場合、ポーリングによる異常検知手法では、異常検知に求められる要件が満たされない場合がある。産業インフラストラクチャ等において稼働する制御システムにおいては、異常の発生を即時に検知し、該異常への対策を迅速に行うことにより、利用者の安全を確保することが求められるためである。しかし、特許文献１には、ポーリング以外の異常検知手法については記載されていない。
　本発明は、上記の状況を考慮してなされたものであり、本発明の目的は、コンテナ型仮想化技術を用いた仮想化システムにおいて、アプリケーションで発生した異常への対応を迅速に行えるようにすることにある。
　本発明の一態様に係る仮想化システムは、複数のアプリケーションの起動に関する設定、及び、アプリケーションの異常終了時に取るべき対処内容が記載されたアプリ起動監視定義ファイルと、アプリ起動監視定義ファイルの記載内容に基づいて複数のアプリケーションを起動させ、起動したアプリケーションの終了を検知し、アプリケーションの異常終了時における対処を行うアプリケーション管理機構部と、を備える。そして、アプリケーション管理機構部は、アプリケーションが実行されるアプリケーションコンテナが起動されることによりアプリケーションコンテナにマウントされ、アプリケーションコンテナのエントリポイントプロセスとして起動される。
　本発明の少なくとも一態様によれば、コンテナ型仮想化技術を用いた仮想化システムにおいて、アプリケーションにおいて発生した異常への対応を迅速に行えるようになる。
　上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
本発明の一実施形態に係る制御サーバーの機能構成例を示すブロック図である。 本発明の一実施形態に係る制御サーバーのハードウェア構成例を示すブロック図である。 本発明の一実施形態に係るアプリ起動監視定義ファイルにおけるアプリケーション起動順の設定が行われる設定画面の表示例を示す図である。 本発明の一実施形態に係るアプリ起動監視定義ファイルにおけるＦＢポリシーの設定が行われる設定画面の表示例を示す図である。 本発明の一実施形態に係るＰｏｄ定義ファイルの設定が行われる設定画面の表示例を示す図である。 本発明の一実施形態に係るイベントハンドリングルールの設定が行われる設定画面の表示例を示す図である。 本発明の一実施形態に係るＰｏｄ及びコンテナの起動時における制御処理の手順の例を示すフローチャートである。 本発明の一実施形態に係るアプリケーション管理機構部による制御処理の手順の例を示すフローチャートである。 本発明の一実施形態に係るＰｏｄ管理コンテナによる制御処理の手順の例を示すフローチャートである。 本発明の一実施形態に係るマイクロサービス実行管理基盤部２０による制御処理の手順の例を示すフローチャートである。
　以下、本発明の実施形態を、図を用いて説明する。各図において、同一の構成には同一の符号を付す。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。
＜制御サーバーの構成＞
　まず、図１を参照して、本発明の仮想化システムが構築される制御サーバーの構成について説明する。図１は、本発明の一実施形態に係る制御サーバー１００の機能構成例を示すブロック図である。本実施形態では、制御サーバー１００上にコンテナ型仮想化技術による仮想化システムが構築される。
　図１に示すように、制御サーバー１００は、Ｐｏｄ１０と、マイクロサービス実行管理基盤部２０と、ＯＳイベント検出部３０と、ＯＳイベント監視部４０と、コンテナエンジン５０と、コンテナ実行基盤制御機構部６０と、を含む。
　Ｐｏｄ１０は、アプリケーションの起動制御を行う最小単位であり、Ｐｏｄ１０は１つ以上のコンテナから構成される。本実施形態では、Ｐｏｄ１０を構成するコンテナは、複数のアプリケーションコンテナ１－１～１－ｎ（ｎは２以上の自然数）、及び、Ｐｏｄ管理コンテナ２である。以下の説明において、アプリケーションコンテナ１－１～１－ｎをそれぞれ識別する必要がない場合、これらをアプリケーションコンテナ１と総称する。
　Ｐｏｄ１０内に含まれるコンテナ同士は、各種リソースやネットワーク（図示略）などを共有する。なお、図１には、制御サーバー１００内に１つのＰｏｄ１０が含まれる例を挙げたが、本発明はこれに限定されず、制御サーバー１００内には複数のＰｏｄが含まれてもよい。
［Ｐｏｄ］
　Ｐｏｄ１０は、複数のアプリケーションコンテナ１と、Ｐｏｄ管理コンテナ２と、を含む。Ｐｏｄ管理コンテナ２（管理コンテナの一例）は、アプリケーションコンテナ１の管理を行うコンテナである。
（アプリケーションコンテナ）
　アプリケーションコンテナ１は、コンテナイメージ１１と、アプリケーション管理機構部１２と、を含む。コンテナイメージ１１は、アプリケーションコンテナ１を動作させるための動作環境テンプレートであり、アプリ起動監視定義ファイルｆｃと、複数のアプリケーションＡｐ－１～Ａｐ－ｍ（ｍは２以上の自然数）と、を含む。以下の説明において、アプリケーションＡｐ－１～Ａｐ－ｍをそれぞれ識別する必要がない場合、これらをアプリケーションＡｐと総称する。なお、コンテナイメージ１１には、アプリケーションＡｐを実行するために必要なオペレーティング・システム（ＯＳ）ライブラリ、依存関係の情報（図示略）等も含まれる。
　アプリケーションＡｐは、コンテナイメージ１１においてはソースコードの形態で記載されており、アプリケーション管理機構部１２のアプリケーション実行部１２１によって、アプリケーションコンテナ１内でアプリケーションとして起動される。以下の説明において、アプリケーションＡｐの最小実行単位であるプロセスを、「タスク」とも称する。
アプリケーション管理機構部１２は、アプリケーションの起動を、アプリ起動監視定義ファイルｆｃの記載内容に基づいて行う。
　アプリ起動監視定義ファイルｆｃは、ユーザにより予め作成されるファイルである。アプリ起動監視定義ファイルｆｃにおいては、アプリケーションコンテナ１におけるアプリケーションの起動に関する設定、及び、アプリケーションの終了検知時に適用するフォールバック（ＦＢ）ポリシー等が定義される。アプリ起動監視定義ファイルｆｃにおけるアプリケーションの起動順の定義例については、後述の図３を参照して詳述する。
　アプリケーション管理機構部１２（アプリケーション管理機構部の一例）は、アプリケーション実行部１２１及びアプリケーション監視部１２２を含む。なお、アプリケーション管理機構部１２の情報は、コンテナイメージ１１には含めておかず、コンテナホスト（図示略）上にバイナリの実行ファイル（以下、「実行バイナリ」と称する）として配置される。コンテナホストは、アプリケーションコンテナ１、Ｐｏｄ管理コンテナ２が実行されるＯＳや装置（制御サーバー１００）などの総称である。そして、アプリケーション管理機構部１２は、アプリケーションコンテナ１の起動時にアプリケーションコンテナ１内に動的にマウント（挿入）され、アプリケーションコンテナ１のエントリプロセスとして起動する。図１には、アプリケーション管理機構部１２がアプリケーションコンテナ１にマウントされた後の状態を示す。
　アプリケーションコンテナ１の起動は、コンテナエンジン５０内のコンテナ実行部５０３の指示によって行われ、コンテナ実行部５０３は、構成情報５０２を参照してアプリケーションコンテナ１の起動を指示する。そして、構成情報５０２においては、アプリケーションコンテナ１のエントリポイントプロセスにアプリケーション管理機構部１２が設定されている。これにより、アプリケーションコンテナ１の起動時に、アプリケーション管理機構部１２がアプリケーションコンテナ１内にマウントされ、アプリケーションコンテナ１のエントリプロセスとして起動する。
　なお、アプリケーションコンテナ１のエントリポイントプロセスをアプリケーション管理機構部１２にする設定は、コンテナ実行基盤制御機構部６０のＰｏｄコンテナ登録部６０１によって行われる。より詳細には、この設定は、Ｐｏｄコンテナ登録部６０１が、アプリケーションコンテナ１内におけるアプリケーション管理機構部１２の配置場所の情報を含むコマンドラインを、Ｐｏｄコンテナ管理部５０１に対して指定することによって行われる。
　アプリケーション管理機構部１２のアプリケーション実行部１２１は、アプリ起動監視定義ファイルｆｃの記載内容に基づいて、アプリケーションコンテナ１内で動作させるアプリケーションの起動、起動順、起動タイミング等を制御する。そしてアプリケーション監視部１２２は、アプリケーション実行部１２１が起動したアプリケーションを子プロセスとして、その状態を監視する。
　また、アプリケーション監視部１２２は、アプリケーション実行部１２１が起動したアプリケーションの終了を検知する。アプリケーション監視部１２２は、例えば、子プロセスからのＳＩＧＣＨＩＬＤシグナル受信に基づいて、子プロセスとして監視中のアプリケーションの終了を検知する。本実施形態では、アプリケーション監視部１２２は、Linux（登録商標）のprctl（PR_SET_CHILD_SUBREAPER）の機能を使用することにより、孫プロセス及び曾孫プロセスも監視対象とすることができる。なお、子、孫、曾孫プロセスの管理手法はこの例に限定されず、他の手法であってもよい。
　そして、アプリケーション監視部１２２は、アプリケーションの終了を検知した場合、アプリケーションの終了要因を確認し、終了要因に応じたハンドリングを行う。終了要因に対応するハンドリングの内容は、アプリ起動監視定義ファイルｆｃ内において、ＦＢポリシーとして規定されている。ＦＢポリシーには、例えば、アプリケーションの再起動ポリシー及びフォールバックレベルの情報等が含まれる。
　「再起動ポリシー」には、アプリケーションが終了した場合におけるアプリケーションの再起動条件、再起動タイミングが設定される。「フォールバックレベル」には、終了したアプリケーションの再起動を行わずに対象のアプリケーションを停止状態とする場合における、同一のアプリケーションコンテナ１内で動作する他アプリケーションの継続動作ポリシーが設定される。
　アプリケーション監視部１２２は、アプリケーションの終了要因が、再起動対象の終了要因以外の終了要因である場合、又は、規定時間以内のアプリケーションの再起動回数が上限を超えた場合、アプリケーションの異常終了を検知する。そして、アプリケーション監視部１２２は、異常終了の検知に対して、フォールバックレベルとして定義されたアクション（ハンドリング）を行う。フォールバックレベルとして定義されたアクションには、例えば、アプリケーションの再起動や、アプリケーションコンテナ１の強制停止などがある。
　一方、アプリケーションの終了要因が再起動対象の終了要因であり、かつ、アプリケーションの再起動回数が上限を超えていない場合、アプリケーション監視部１２２は、再起動ポリシーに基づいてアプリケーションの再起動を実行する。
　さらに、アプリケーション監視部１２２は、異常終了の事象をイベントとしてＰｏｄ管理コンテナ２に通知する。イベントは、例えば、識別子としてのイベントＩＤ及びイベントを説明する文字列（メッセージ）、イベントの付加情報が記載されるボディで構成される。イベントＩＤは、イベント識別子、イベントの種別を示す情報、及び、イベントのレベルを示す情報で構成される。イベントレベルは、イベントに対する対処の緊急度を示す情報であり、例えば、「Critical」、「Error」、「Warning」、「Notice」、「Info」等がある。
　「Critical」は、直ちに何らかの対処が必要な重大なエラー等を示すイベントに設定されるレベルであり、「Error」は、状況に応じて何らかの対処が必要なシステム障害等のイベントに設定されるレベルである。「Warning」は、システムとしては動作継続可能であるが、経過によって障害発生につながる可能性のある事象の検知時に発行されるイベントに対して設定されるレベルである。「Notice」は、システムとしては動作継続可能であるが、通知すべき事象が発生した場合に発行するイベントに設定されるレベルである。「Info」は、イベントの記録や通知のみを目的としたイベントに対して設定されるレベルである。
　つまり、本実施形態によれば、アプリケーション監視部１２２によって異常が確認された事象の詳細情報が、イベントとして、Ｐｏｄ管理コンテナ２に通知される。なお、イベントの構成は上述した例に限定されず、また、イベントレベルの設定例も、上述した例に限定されない。
［アプリケーション管理機構部の役割］
　ここで、本実施形態に係るアプリケーションコンテナ１がアプリケーション管理機構部１２を備える理由について説明する。従来の技術においては、１つのコンテナにおいて１つのアプリケーションを動作させ、複数のコンテナを起動及び連携させてシステムを構成することが一般的に行われていた。しかし、産業インフラストラクチャにおいて使用される制御システムでは、１００以上等の非常に多くのアプリケーションが動作する。したがって、コンテナとアプリケーションとを一対一で対応付けた場合、コンテナ制御の複雑化とコンテナの構成管理の困難化とが懸念される。
　このような懸念に対する対策として、１つのコンテナ内で複数のアプリケーションを動作させる運用形態が考えられる。そして、このような運用を行う場合においては、コンテナの起動後に生成されるエントリポイントプロセスの信頼性が特に重要になる。エントリポイントプロセスにおいては、初期化などのアプリケーションのタスク動作に必要となる処理が実行されるためである。また、コンテナにおけるエントリポイントプロセスが停止した場合に、コンテナ自体を強制的に停止する仕様が設計される場合もあるため、エントリポイントプロセスが正常に実行されることは重要な意味を持つ。
　本実施形態では、アプリケーション管理機構部１２のアプリケーション実行部１２１が、複数の各アプリケーションコンテナ１のエントリポイントプロセスの生成及び実行を一元的に行う。アプリケーション実行部１２１によってこのような制御が行われることにより、アプリケーションコンテナ１のエントリポイントプロセスの実行の信頼性を向上させることができる。
　また、本実施形態に係るアプリケーション管理機構部１２は、上述したように、アプリケーションコンテナ１内で動作するプログラムであるが、コンテナイメージ１１内には含まれず、コンテナホスト上に実行バイナリとして配置される。そして、アプリケーション管理機構部１２は、アプリケーションコンテナ１の起動時にアプリケーションコンテナ１内に動的にマウント（挿入）され、アプリケーションコンテナ１のエントリプロセスとして起動する。
　したがって、本実施形態によれば、仮にアプリケーション管理機構部１２が改修される場合にも、アプリケーション管理機構部１２の実行バイナリの内容を修正するだけで済む。つまり、アプリケーション管理機構部１２の情報を予めコンテナイメージ１１内に含めた場合のように、コンテナイメージ１１から生成されるアプリケーションコンテナ１自体の再作成をする必要がなくなる。
　また、アプリケーション管理機構部１２をコンテナイメージ１１内に含めないことにより、Ｐｏｄ１０に含まれる複数のアプリケーション管理機構部１２のバージョンの統一も容易に行えるようになる。これにより、同一のＯＳ上で動作させる複数のアプリケーション管理機構部１２の各バージョンを同一のバージョンに統一できる。したがって、本実施形態によれば、アプリケーションの開発者が、複数のバージョンの共存を考慮した作り込み等を行う手間も省くことができる。
（Ｐｏｄ管理コンテナ）
　Ｐｏｄ管理コンテナ２は、Ｐｏｄ１０内のアプリケーションコンテナ１の異常検知及び管理を行うコンテナである。Ｐｏｄ管理コンテナ２は、各Ｐｏｄ１０に対してサイドカーコンテナとして追加される。
　Ｐｏｄ管理コンテナ２がこのように構成されることにより、Ｐｏｄ管理コンテナ２の改修が行われた場合に、コンテナイメージ１１から生成されるアプリケーションコンテナ１自体を再作成する必要がなくなる。また、同一のＯＳ上で動作する複数のＰｏｄ管理コンテナ２のバージョンを同一バージョンに統一することも容易となる。したがって、本実施形態によれば、アプリケーションの開発者が、複数のバージョンの共存を考慮した作り込み等を行う手間を省くことができる。
　Ｐｏｄ管理コンテナ２は、Ｐｏｄ内コンテナ監視部２１と、Ｐｏｄ内イベント受信部２２と、を含む。Ｐｏｄ内コンテナ監視部２１は、各アプリケーションコンテナ１のアプリケーション監視部１２２から送信されるイベントを受信する。そして、Ｐｏｄ内コンテナ監視部２１は、受信したイベントの情報をＰｏｄ内イベント受信部２２に出力する。
　Ｐｏｄ内イベント受信部２２は、Ｐｏｄ内コンテナ監視部２１からイベントを受信した場合、イベント送信元のアプリケーションコンテナ１に対して予め設定されたＦＢポリシーに基づいて、イベントに応じたハンドリングを行う。各アプリケーションコンテナ１のＦＢポリシーは、Ｐｏｄ定義ファイルｆｐにおいて予め定義される。ユーザによるＰｏｄ定義ファイルｆｐの定義例については、後述の図５を参照して詳述する。
　Ｐｏｄ内イベント受信部２２が行うハンドリングには、例えば、異常が検知されたアプリケーションコンテナ１の強制終了、Ｐｏｄ１０内の他のアプリケーションコンテナ１の強制終了などがある。つまり、Ｐｏｄ内イベント受信部２２は、アプリケーションコンテナ１又はＰｏｄ１０の単位での異常処理制御を行う。なお、Ｐｏｄ内イベント受信部２２は、アプリケーションの内容の分析等は行わないが、アプリケーションコンテナ１又はＰｏｄ１０のステータスの管理や、障害ログ等の詳細情報の記録及び保持は行うものとする。
　さらに、Ｐｏｄ内イベント受信部２２は、異常検知の事象をイベントとしてマイクロサービス実行管理基盤部２０に送信する。
［マイクロサービス実行管理基盤部］
　マイクロサービス実行管理基盤部２０（サービス実行管理基盤部の一例）は、制御サーバー１００内のＰｏｄ１０を管理及びイベントの一元管理を行う機能部である。マイクロサービス実行管理基盤部２０は、Ｐｏｄ監視部２０１と、システム内イベント管理部２０２と、を含む。
　Ｐｏｄ監視部２０１は、Ｐｏｄ管理コンテナ２のＰｏｄ内イベント受信部２２から送信されたイベントの情報を、システム内イベント管理部２０２に出力する。
　システム内イベント管理部２０２は、Ｐｏｄ監視部２０１又はＯＳイベント監視部４０から入力されたイベントを一元管理する。また、システム内イベント管理部２０２は、事前にユーザが定義したイベントハンドリングルールＲｃに従って、イベントに対応付けられたアクション（ハンドリング）を実行する。システム内イベント管理部２０２が行うアクションには、例えば、コンテナホストＯＳの強制停止、制御サーバー１００の電源オフ又は再起動等がある。ユーザによるイベントハンドリングルールＲｃの定義例については、後述の図６を参照して詳述する。
　ＯＳイベント検出部３０は、Ｐｏｄ１０及びコンテナの動作する実行基盤における異常等のイベント（以下「ＯＳイベント」と称する）の発生を検知する。ＯＳイベント検出部３０が検出するイベントには、例えば、制御サーバー１００の不揮発性ストレージ２２０（図２参照）の障害や、不図示のネットワークに関する障害などがある。
　ＯＳイベント監視部４０（イベント監視部の一例）は、ＯＳイベント検出部３０で検知されたＯＳイベントを受け取り、マイクロサービス実行管理基盤部２０のシステム内イベント管理部２０２に出力する。より詳細には、ＯＳイベント監視部４０は、ＯＳイベント検出部３０が様々な対象から様々な検知方法で検出した障害の情報を、システム内イベント管理部２０２において管理可能なイベントの情報に再構成して、システム内イベント管理部２０２に出力する。
［コンテナエンジン］
　コンテナエンジン５０は、Ｐｏｄコンテナ管理部５０１と、構成情報５０２と、コンテナ実行部５０３と、を含む。
　Ｐｏｄコンテナ管理部５０１は、コンテナ実行基盤制御機構部６０のＰｏｄコンテナ登録部６０１によって登録されたＰｏｄ１０及びコンテナの情報に基づいて、構成情報５０２を構成する。また、Ｐｏｄコンテナ管理部５０１は、Ｐｏｄコンテナ登録部６０１から入力されたＰｏｄ１０及び／又はコンテナの構成の変更情報に基づいて、構成情報５０２の内容を変更する。
　構成情報５０２は、Ｐｏｄ１０、アプリケーションコンテナ１、Ｐｏｄコンテナ２の構成に関する情報、コンテナイメージ１１の格納場所等の情報が記載されたファイルである。
　コンテナ実行部５０３は、コンテナ実行基盤制御機構部６０のＰｏｄ実行指示部６０２による指示に従って、構成情報５０２に記載の情報を参照して、アプリケーションコンテナ１及びＰｏｄ管理コンテナ２を起動する。
［コンテナ実行基盤制御機構部］
　コンテナ実行基盤制御機構部６０は、Ｐｏｄ１０内のコンテナの操作を行うインターフェースであり、Ｐｏｄコンテナ登録部６０１と、Ｐｏｄ実行指示部６０２と、を含む。
　Ｐｏｄコンテナ登録部６０１は、ユーザにより入力される指示に基づいて、Ｐｏｄ定義ファイルｆｐを参照して、コンテナエンジン５０に対して、Ｐｏｄ１０及びコンテナの登録を指示する。例えば、Ｐｏｄコンテナ登録部６０１は、Ｐｏｄ定義ファイルｆｐの記載内容に基づいて、同一のＰｏｄ１０内にアプリケーションコンテナ１とＰｏｄ管理コンテナ２との両方を含めるように、コンテナエンジン５０に構成情報５０２を作成させる。
　Ｐｏｄ実行指示部６０２は、ユーザによる指示に基づいて、コンテナエンジン５０に対して、Ｐｏｄ１０、アプリケーションコンテナ１の起動などを指示する。
＜計算機のハードウェア構成例＞
　次に、本実施形態に係る制御サーバー１００の機能を実現するための装置のハードウェア構成について、図２を参照して説明する。図２は、制御サーバー１００のハードウェア構成例を示すブロック図である。図２に示す計算機２００は、いわゆるコンピュータとして用いられるハードウェアである。
　計算機２００は、バスＢにそれぞれ接続された制御部２１０と、不揮発性ストレージ２２０と、表示部２３０と、操作入力部２４０と、通信Ｉ／Ｆ（Interface）２５０と、を備える。
　制御部２１０は、ＣＰＵ（Central Processing Unit）２１１と、ＲＯＭ（Read Only Memory）２１２と、ＲＡＭ（Random Access Memory）２１３と、を備える。
　ＣＰＵ２１１は、本実施形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ２１２から読み出してＲＡＭ２１３に展開して実行する。ＲＡＭ２１３には、演算処理の途中に発生した変数やパラメータ等が一時的に書き込まれる。
　なお、制御部２１０は、ＣＰＵ２１１の代わりに、ＭＰＵ（Micro-Processing Unit）等の処理装置を備えてもよい。もしくは、制御部２１０において、ＣＰＵとＭＰＵとが併用されてもよい。
　不揮発性ストレージ２２０としては、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、不揮発性のメモリカード等を用いることができる。この不揮発性ストレージ２２０には、ＯＳ、各種のパラメータの他に、計算機２００を機能させるためのプログラム等が記録される。なお、プログラムは、ＲＯＭ２１２に格納されてもよい
　表示部２３０は、例えば、ＬＣＤ（Liquid Crystal Display）等で構成されるモニタであり、計算機２００で行われる処理の結果等を表示する。
　操作入力部２４０は、例えば、キーボード、マウス、タッチセンサ等によって構成され、ユーザによる操作に応じた操作信号を生成してＣＰＵ２１１に供給する。
　なお、表示部２３０と操作入力部２４０とは、タッチパネルとして一体に構成されてもよい。また、計算機２００は、表示部２３０及び操作入力部２４０を備えない構成とされてもよい。
　プログラムは、コンピュータが読取り可能なプログラムコードの形態で格納され、ＣＰＵ２１１は、当該プログラムコードに従った動作を逐次実行する。つまり、ＲＯＭ２１２又は不揮発性ストレージ２２０は、コンピュータによって実行されるプログラムを格納した、コンピュータ読取可能な非一過性の記録媒体の一例として用いられる。
　通信Ｉ／Ｆ２５０には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ネットワーク又は通信線を介して外部装置との間で各種のデータを送受信することが可能である。
＜アプリ起動監視定義ファイルにおけるアプリケーション起動順の設定例＞
　次に、図３を参照して、アプリ起動監視定義ファイルｆｃにおけるアプリケーション起動順の設定例について説明する。図３は、アプリ起動監視定義ファイルｆｃにおけるアプリケーション起動順の設定が行われる設定画面Ｓｃ１の表示例を示す図である。本実施形態では、アプリ起動監視定義ファイルｆｃ等の各種設定ファイルは、例えば、ＹＡＭＬ（YAML Ain’t Markup Language）形式等で記述される。
　図３に示す設定画面Ｓｃ１の最上段には、「kind: Appman」と記載されている。これは、設定対象の項目の種別は「Appman」（アプリケーション管理機構部１２）であることを示す。「spec」は設定の記述を示すコマンドであり、続く「tasks」以下において、アプリケーションの起動順が設定されている。taskは、アプリケーションコンテナ１内で実行させるアプリケーションのプロセス（タスク）を示す。
　「tid」は、アプリケーションとして実行されるタスクのＩＤ（識別子）である。図３に示す例では、設定画面Ｓｃ１において、「task1」、「task2」のそれぞれによって識別される各アプリケーションをこの順に起動させることが指示されている。アプリ起動監視定義ファイルｆｃにおいてこのような設定がされることにより、task1のアプリケーションの起動が完了した後に、task2のアプリケーションの起動が行われることが保証される。
　「command」は、設定の定義の記述を示すコマンドであり、図３に示す例では、設定画面Ｓｃ１において「type」、「execStart」の各設定の定義が記述されている。「type」は、アプリケーションのタイプを示し、「execStart」においては、アプリケーションを起動するための実行コマンドが指定される。
　アプリケーションのタイプの「oneshot」は、コンテナ起動時のみに実行され、常駐化しないアプリケーションに対して設定されるタイプである。「oneshot」のタイプのアプリケーションにおいてアプリケーション管理機構部１２による管理対象となるプロセスは、エントリポイントプロセスである。アプリケーション管理機構部１２のアプリケーション実行部１２１は、該アプリケーションに係るエントリポイントプロセスの終了時に、該アプリケーションの起動が完了したと判定する。
　「simple」は、他タスクとの厳密な起動待ち合わせが不要であるアプリケーションに対して設定されるタイプである。「simple」のタイプのアプリケーションにおいてアプリケーション管理機構部１２による管理対象となるプロセスも、エントリポイントプロセスである。アプリケーション管理機構部１２のアプリケーション監視部１２２は、該アプリケーションに係るエントリポイントプロセスの生成完了時に、該アプリケーションの起動が完了したと判定する。
　本実施形態では、アプリケーション管理機構部１２のアプリケーション実行部１２１が、アプリ起動監視定義ファイルｆｃにおいて規定されたアプリケーションの起動順に従って、アプリケーションコンテナ１内の各アプリケーションを起動させる。このとき、アプリケーション実行部１２１は、アプリ起動監視定義ファイルｆｃにおいて規定されたアプリケーションのタイプに応じて、アプリケーションの起動完了判定を行う。そして、アプリケーション実行部１２１は、起動させたアプリケーションの起動完了判定後に、次のアプリケーションを起動させる。
　つまり、本実施形態によれば、起動順が前のアプリケーションが起動完了状態に遷移したタイミングで、後続アプリケーションが起動される。したがって、本実施形態によれば、アプリケーションの開発者が、アプリケーションの起動待ち合わせ処理の作り込み等を行う手間を省くことができる。
　なお、アプリケーションのタイプには、図３に示した例の他に「forking」等がある。
「forking」は、アプリケーションの起動初期化処理完了後にforkし、子プロセス側でメイン処理を継続するプログラム構造のアプリケーションに対して設定されるタイプである。「fork」は、親プロセスを２つの同一内容のプロセスに分岐させるシステムコールである。
　「forking」のタイプのアプリケーションにおいてアプリケーション管理機構部１２による管理対象となるプロセスは、エントリポイントプロセスの子プロセス、すなわち孫プロセスである。アプリケーション管理機構部１２のアプリケーション監視部１２２は、該アプリケーションに係るエントリポイントプロセスの終了時に、該アプリケーションの起動が完了したと判定する。つまり、forkingを指定して起動された孫プロセスについても、アプリケーション管理機構部１２の管理対象となる。なお、アプリケーションのタイプは、上述した例に限定されない。
＜アプリ起動監視定義ファイルにおけるＦＢポリシーの設定例＞
　次に、図４を参照して、アプリ起動監視定義ファイルｆｃにおけるＦＢポリシーの設定例について説明する。図４は、アプリ起動監視定義ファイルｆｃにおけるＦＢポリシーの設定が行われる設定画面Ｓｃ２の表示例を示す図である。
　図４に示す設定画面Ｓｃ２において、タスクＩＤが「task3」であるアプリケーションについて、「command」の項目に続いて「fallback」の項目の設定が行われている。「fallback」の項目では、ＦＢポリシーが記述される。設定画面Ｓｃ２においては、「fallback」の項目内で「level」及び「restartPolicy」の各項目の設定が記述されている。
　「level」の項目では、フォールバックレベルが設定される。図４に示す例では、タスクＩＤが「task3」であるアプリケーションに対して、“critical”のレベルが設定されている。“critical”のレベルが設定されたアプリケーションが停止した場合、アプリケーション管理機構部１２のアプリケーション監視部１２２（図１参照）は、アプリケーションコンテナ１内で起動している他のアプリケーションを全て停止させる。そして、他のアプリケーションが全て停止した後、アプリケーションコンテナ１が停止状態に遷移する。
　フォールバックレベルには、他に「normal」等がある。「normal」のレベルが設定されたアプリケーションに異常が発生した場合、アプリケーション管理機構部１２のアプリケーション監視部１２２は、該アプリケーションのみを停止させ、他アプリケーションは継続して動作させる。アプリケーション管理機構部１２のアプリケーション監視部１２２によってこのような制御が行われることにより、アプリケーションコンテナ１においては、一部のアプリケーションが停止した状態のまま動作が継続される。すなわち、該アプリケーションコンテナ１において、機能縮退状態でコンテナ動作が継続される。
　「restartPolicy」の項目では、再起動ポリシーが設定される。図４に示す例では、タスクＩＤが「task3」であるアプリケーションの再起動ポリシーとして、以下の設定が記述されている。
　restart: on-success
　startLimitIntervalSec: 10
　startLimitBurst: 5
　restartSec: 1000
　「restart」の項目では、再起動トリガ条件が設定される。再起動トリガ条件においては、アプリケーションの終了要因に対する、アプリケーションの再起動の要否の情報が設定される。「startLimitIntervalSec」の項目では、前回、アプリケーションの再起動を行ってから再起動回数をリセットするまでに要する経過時間が設定される。「startLimitBurst」の項目では、アプリケーションの再起動の上限回数が設定される。アプリケーションの再起動は、「startLimitIntervalSec」の項目において設定された時間内において、「startLimitBurst」の項目で背呈された回数に到達するまでの間行われる。「restartSec」の項目では、アプリケーションの再起動の間隔時間が設定される。
　本実施形態では、アプリケーション管理機構部１２のアプリケーション監視部１２２によって、各アプリケーションに対して設定されたＦＢポリシーに応じたハンドリングが行われる。したがって、各アプリケーションに対するＦＢポリシーをアプリ起動監視定義ファイルｆｃにおいてユーザが適切に定義しておくことにより、異常発生時のハンドリングが適切に実施されるようになる。なお、アプリ起動監視定義ファイルｆｃに設定されるＦＢポリシーの項目は、図４に示した例に限定されない。
＜Ｐｏｄ定義ファイルの設定例＞
　次に、図５を参照して、Ｐｏｄ定義ファイルｆｐの設定例について説明する。図５は、Ｐｏｄ定義ファイルｆｐの設定が行われる設定画面Ｓｃ３の表示例を示す図である。
　設定画面Ｓｃ３の最上段にある「apiVersion」の項目には、ＡＰＩ（Application Programming Interface）スキーマのバージョンの情報が設定される。続く「kind」の項目では、設定対象となる項目の種別の情報が設定される。図５に示す設定画面Ｓｃ３においてはＰｏｄ定義ファイルｆｐの設定が行われるため、「kind」の項目には“Pod”が指定されている。
　「metadata」の項目においては、Ｐｏｄ１０を識別するための情報が設定される。「name」の項目では、Ｐｏｄ１０の名称が設定され、「version」の項目では、Ｐｏｄ１０のバージョンの情報が設定される。
　続く「spec」の項目においては、Ｐｏｄ１０内の全コンテナに共通する設定項目が設定される。「resource」の項目では、Ｐｏｄ１０に割り当てるマシンリソースに関する情報が設定される。「limits」の項目では、リソースの制限値が設定される。図５に示す例では、「limits」の項目において「cpuset」の項目の設定が行われている。「cpuset」の項目では、Ｐｏｄ１０に割り当てるＣＰＵコアの指定が行われる。図５に示す例では、“cpus：“0-1””と記述されている。この記述は、Ｐｏｄ１０に対してＣＰＵコア番号の“0-1”を割り当てることを指示するものである。
　「stopOnContainerFailure」の項目では、Ｐｏｄ１０内のいずれかのコンテナが停止した場合に、Ｐｏｄ１０に含まれる他のコンテナも停止させてＰｏｄ１０を停止状態にするか否かの情報が設定される。“true”が設定された場合、Ｐｏｄ１０内のいずれかのコンテナが停止した場合に、Ｐｏｄ１０に含まれる他のコンテナも停止されＰｏｄ１０が停止する。一方、“false”が設定された場合、Ｐｏｄ１０内の他のコンテナの動作は継続される。
　なお、Ｐｏｄ１０の起動又は停止の動作を規定する項目には、他に「startingDeadline Seconds」、「stoppingDeadline Seconds」、「startingContainer DeadlineSeconds」、「stoppingContainer DeadlineSeconds」等がある。「startingDeadline Seconds」の項目では、Ｐｏｄ１０の起動タイムアウト時間が設定される。「stoppingDeadline Seconds」の項目では、Ｐｏｄ１０の停止タイムアウト時間が設定される。「startingContainer DeadlineSeconds」の項目では、Ｐｏｄ１０の起動時における各コンテナの起動タイムアウト時間が設定される。「stoppingContainer DeadlineSeconds」の項目では、Ｐｏｄ１０の停止時における各コンテナの停止タイムアウト時間が設定される。
　上記の各項目に設定されたＰｏｄ起動タイムアウト、又は、コンテナ起動タイムアウトが発生した場合、Ｐｏｄ内コンテナ監視部２１は、起動途中及び起動済みのコンテナを強制停止処理により停止させる。このとき、Ｐｏｄ内コンテナ監視部２１は、コンテナ内で動作するアプリケーションにシグナルを送信することにより、該アプリケーションを強制停止させる。また、Ｐｏｄ停止タイムアウト又はコンテナ停止タイムアウトが発生した場合、Ｐｏｄ内コンテナ監視部２１は、停止途中のコンテナを強制的に停止させる。その後、Ｐｏｄ内コンテナ監視部２１は、後続のＰｏｄ１０内の起動状態であるコンテナを強制停止処理により停止させる。
　続く「containers」の項目では、Ｐｏｄ１０内に含めるコンテナに関する情報が設定される。「image」の項目では、コンテナが使用するコンテナイメージ１１の情報が設定され、「name」の項目では、コンテナの名称が設定される。「volumesFrom」の項目では、コンテナが使用するデータベースの名称が設定される。なお、Ｐｏｄ定義ファイルｆｐに設定される項目は、図５に示した例に限定されない。
＜イベントハンドリングルールの設定例＞
　次に、図６を参照して、マイクロサービス実行管理基盤部２０のシステム内イベント管理部２０２が参照するイベントハンドリングルールＲｃの設定例について説明する。図６は、イベントハンドリングルールＲｃの設定が行われる設定画面Ｓｃ４の表示例を示す図である。
　設定画面Ｓｃ４の最上段にある「apiVersion」の項目は、図５に示した設定画面Ｓｃ３におけるものと同じであるため、説明は省略する。続く「kind」の項目では、イベントハンドリングルールＲｐの種別を示す“CEPRule”が指定されている。
　続く「spec」の項目では、「rules」の項目が設定される。「rules」の項目は、イベントを処理（ハンドリング）する場合におけるルールが設定される。「source」の項目には、イベントソース、すなわち、イベントの発生箇所を示す情報が設定される。図６に示す例では、イベントソースには“container”、すなわちコンテナが設定されている。
　「conditions」の項目においては、ルールに規定された処理を行う対象となるイベントを絞り込むための条件が設定される。図６に示す例では、「conditions」の項目において、イベントソースが“container”であること、イベントレベルが“Error”であること、イベントのボディ内の“app_id”が“x1000”であること、の３つの条件がＡＮＤ条件として定義されている。
　そして、システム内イベント管理部２０２は、「conditions」の項目に設定されたすべての条件を満たすイベントに対して、「actions」の項目で設定されるアクション（ハンドリング）を行う。図６に示す例では、「actions」の項目においては“haltSystem”のアクションが定義されている。“haltSystem”は、コンテナホストのＯＳを強制停止させるアクションである。
　イベントに対して行われるアクションには、他に、「powerOFFSystem」、「rebootSystem」、「panicSystem」等がある。「powerOFFSystem」は、コンテナホストＯＳの強制停止を行い、制御サーバー１００の電源をオフにするアクションである。「rebootSystem」は、コンテナホストＯＳの強制停止後にＯＳを再起動するアクションである。「panicSystem」は、故意にカーネルパニックを発生させてコンテナホストＯＳを強制停止させるアクションである。なお、イベントハンドリングルールＲｃに設定されるイベント及び該イベントに対して行われるアクションは、図６に示した例に限定されない。
＜制御サーバーによる仮想化システム制御方法＞
　次に、図７～図１０を参照して、本実施形態に係る制御サーバー１００による仮想化システムの制御方法について説明する。図７は、Ｐｏｄ及びコンテナの起動時における制御処理の手順の例を示すフローチャートである。図８は、アプリケーション管理機構部１２による制御処理の手順の例を示すフローチャートである。図９は、Ｐｏｄ管理コンテナ２による制御処理の手順の例を示すフローチャートである。図１０は、マイクロサービス実行管理基盤部２０による制御処理の手順の例を示すフローチャートである。
［Ｐｏｄ及びコンテナの起動時における制御処理］
　最初に、図７を参照して、Ｐｏｄ及びコンテナの起動時における制御処理の手順の例について説明する。まず、コンテナエンジン５０のコンテナ実行部５０３（図１参照）は、構成情報５０２の記載内容に基づいて、Ｐｏｄ１０を起動させる（ステップＳ１）。
　次いで、Ｐｏｄ１０の起動に連動して、コンテナホスト上に実行バイナリとして配置されたＰｏｄ管理コンテナ２がＰｏｄ１０内にマウント（挿入）され、Ｐｏｄ１０のエントリプロセスとして起動される（ステップＳ２）。次いで、コンテナエンジン５０のコンテナ実行部５０３は、アプリケーションコンテナ１を起動させる（ステップＳ３）。
　次いで、アプリケーションコンテナ１の起動に連動して、コンテナホスト上に実行バイナリとして配置されたアプリケーション管理機構部１２が、ステップＳ３で起動された各アプリケーションコンテナ１内にマウントされる。そして、アプリケーション管理機構部１２は、アプリケーションコンテナ１のエントリプロセスとして起動される（ステップＳ４）。
　次いで、アプリケーション管理機構部１２のアプリケーション実行部１２１は、アプリ起動監視定義ファイルｆｃに定義された起動順に従って、アプリケーションコンテナ１内でアプリケーションを起動する（ステップＳ５）。ステップＳ５の処理後、Ｐｏｄ及びコンテナの起動時における制御処理は終了する。
［アプリケーション管理機構部による制御処理］
　次に、図８を参照して、アプリケーション管理機構部１２による制御処理について説明する。まず、アプリケーション管理機構部１２のアプリケーション監視部１２２は、アプリケーションの終了を検知したか否かを判定する（ステップＳ１１）。ステップＳ１１で、アプリケーションの終了は検知されていないと判定された場合（ステップＳ１１がＮＯ）、アプリケーション監視部１２２はステップＳ１１の判定を繰り返す。
　一方、ステップＳ１１でアプリケーションの終了が検知されたと判定された場合（ステップＳ１１がＹＥＳ）、アプリケーション監視部１２２は、アプリケーションの終了要因を確認する（ステップＳ１２）。次いで、アプリケーション監視部１２２は、アプリケーションの終了要因は再起動対象の終了要因であるか否かを判定する（ステップＳ１３）。
アプリケーションの終了要因が再起動対象であるか否かは、アプリ起動監視定義ファイルｆｃにおいて定義されている。
　ステップＳ１３で、アプリケーションの終了要因は再起動対象の終了要因でないと判定された場合（ステップＳ１３がＮＯ）、アプリケーション監視部１２２は、アプリ起動監視定義ファイルｆｃに規定されたフォールバックレベルに基づくハンドリングを行う（ステップＳ１４）。ステップＳ１４において、アプリケーション監視部１２２は、停止状態となるアプリケーションの特性（タイプ）に応じた他アプリケーションの継続動作（縮退動作）、又は、アプリケーションの一括停止等のアクションを行う。
　一方、ステップＳ１３で、アプリケーションの終了要因は再起動対象の終了要因であると判定された場合（ステップＳ１３がＹＥＳ）、アプリケーション監視部１２２は、規定時間内の再起動回数は再起動回数の上限値を超えたか否かを判定する（ステップＳ１５）。ステップＳ１５で、再起動回数の上限値を超えたと判定された場合（ステップＳ１５がＹＥＳ）、アプリケーション監視部１２２は、ステップＳ１４の処理を行う。すなわち、フォールバックレベルに基づくハンドリングを行う。
　一方、ステップＳ１５で、再起動回数の上限値を超えていないと判定された場合（ステップＳ１５がＮＯ）、アプリケーション監視部１２２は、アプリ起動監視定義ファイルｆｃに規定された再起動ポリシーに基づいて、アプリケーションの再起動を実行する（ステップＳ１６）。ステップＳ１４又はステップＳ１６の処理後、アプリケーション監視部１２２は、アプリケーション終了の事象をイベントとしてＰｏｄ管理コンテナ２に送信する（ステップＳ１７）。ステップＳ１７の処理後、アプリケーション管理機構部１２による制御処理は終了する。
［Ｐｏｄ管理コンテナによる制御処理］
　次に、図９を参照して、Ｐｏｄ管理コンテナ２による制御処理について説明する。まず、Ｐｏｄ管理コンテナ２のＰｏｄ内イベント受信部２２は、アプリケーションコンテナ１のアプリケーション管理機構部１２からイベントを受信したか否かを判定する（ステップＳ２１）。ステップＳ２１で、イベントは受信していないと判定された場合（ステップＳ２１がＮＯ）、Ｐｏｄ内イベント受信部２２は、ステップＳ２１の判定を繰り返す。
　一方、ステップＳ２１で、イベントを受信したと判定された場合（ステップＳ２１がＹＥＳ）、Ｐｏｄ内イベント受信部２２は、イベントに対応付けられたアプリケーションコンテナ１の情報、及び、当該アプリケーションコンテナ１に対応付けられたＦＢポリシーに基づいて、イベントに対応するハンドリングを実行する（ステップＳ２２）。アプリケーションコンテナ１に対応するＦＢポリシーは、Ｐｏｄ定義ファイルｆｐにおいて予め定義される。
　Ｐｏｄ内イベント受信部２２がステップＳ２２で行うハンドリングには、例えば、異常が確認されたアプリケーションコンテナ１の強制終了や、Ｐｏｄ１０内の他のアプリケーションコンテナ１の強制終了などがある。ステップＳ２２の処理後、Ｐｏｄ管理コンテナ２による制御処理は終了する。
［マイクロサービス実行管理基盤部による制御処理］
　次に、図１０を参照して、マイクロサービス実行管理基盤部２０による制御処理について説明する。まず、マイクロサービス実行管理基盤部２０のＰｏｄ監視部２０１は、Ｐｏｄ管理コンテナ２からイベントを受信したか否かを判定する（ステップＳ３１）。ステップＳ３１で、イベントは受信していないと判定された場合（ステップＳ３１がＮＯ）、Ｐｏｄ監視部２０１は、ステップＳ３１の判定を繰り返す。
　一方、ステップＳ３１で、イベントを受信したと判定された場合（ステップＳ３１がＹＥＳ）、Ｐｏｄ監視部２０１は、イベントの情報をシステム内イベント管理部２０２に送信する。そして、システム内イベント管理部２０２は、当該イベントに対応付けられたイベントハンドリングルールＲｃ基づいて、イベントに対応するハンドリングを実行する（ステップＳ３２）。ステップＳ３２でシステム内イベント管理部２０２が実行するハンドリングには、例えば、カーネルパニックを発生させることによるコンテナホストＯＳの停止等がある。
　システム内イベント管理部２０２が実行するハンドリングには、例えば、コンテナホストのＯＳの強制停止、制御サーバー１００の電源オフ、コンテナホストＯＳの再起動等がある。ステップＳ３２の処理後、Ｐｏｄ管理コンテナ２による制御処理は終了する。
　上述した実施形態では、アプリケーション管理機構部１２は、アプリ起動監視定義ファイルｆｃの記載内容に基づいて複数のアプリケーションを起動させ、起動したアプリケーションの終了を検知し、アプリケーションの異常終了時における対処を行う。そして、アプリケーション管理機構部１２は、アプリケーションコンテナ１の起動時にアプリケーションコンテナ１にマウントされ、アプリケーションコンテナ１のエントリポイントプロセスとして起動される。したがって、本実施形態によれば、アプリケーションコンテナ１のエントリポイントプロセスとして起動されるアプリケーション管理機構部１２が、アプリケーションの異常終了を検知して、アプリ起動監視定義ファイルｆｃに定義された対処を取ることができる。それゆえ、本実施形態によれば、コンテナ型仮想化技術を用いた仮想化システムにおいて、アプリケーションにおいて発生した異常への対応を迅速に行えるようになる。
　また、上述した実施形態に係る制御サーバー１００は、複数のアプリケーションコンテナ１の監視を行うＰｏｄ管理コンテナ２を備える。そして、Ｐｏｄ管理コンテナ２は、Ｐｏｄ１０の起動時にＰｏｄ１０にマウントされ、Ｐｏｄ１０のエントリポイントプロセスとして起動される。したがって、本実施形態によれば、アプリケーションコンテナ１内で動作する各アプリケーションにおける異常だけでなく、アプリケーションコンテナ１自体の異常の検知及び異常検知時の対処も行えるようになる。
　また、上述した実施形態に係る制御サーバー１００は、Ｐｏｄ管理コンテナ２の監視、及び、Ｐｏｄ管理コンテナ１０から送信されるイベントに対するアクションを行うサービス実行管理基盤部２０をさらに備える。したがって、本実施形態によれば、Ｐｏｄ管理コンテナ２自体の異常の検知及び異常検知時の対処も行えるようになる。
　また、上述した実施形態では、ＯＳイベント検出部３０が検出したコンテナホストにおける異常の情報が、ＯＳイベント監視部４０によってマイクロサービス実行管理基盤部２０に送信される。そして、マイクロサービス実行管理基盤部２０のシステム内イベント管理部２０２は、ＯＳイベント監視部４０から受信したイベントに対するハンドリングを実施する。したがって、本実施形態によれば、例えば、Ｐｏｄ１０全体にその影響が波及してしまうようなイベントがコンテナホストにおいて発生した場合にも、システム内イベント管理部２０２によって適切なハンドリングが行われるようになる。
　また、上述した実施形態において、アプリケーション管理機構部１２で生成されてＰｏｄ管理コンテナ２を介してマイクロサービス実行管理基盤部２０に送信されるイベントには、イベントに対する対処の緊急度を示すイベントレベルの情報が含まれる。そして、マイクロサービス実行管理基盤部２０のシステム内イベント管理部２０２は、高いイベントレベルが付与されたイベントに対する対処を優先的に行う。したがって、本実施形態によれば、迅速な対処が必要となる重要な異常に対して、すばやくアクションが取られるようになる。
　また、上述した実施形態では、アプリケーション管理機構部１２は、アプリケーションコンテナ１が起動するコンテナホスト上に実行ファイルとして実装される。すなわち、アプリケーション管理機構部１２はコンテナイメージ１１上に記載されない。したがって、本実施形態によれば、アプリケーション管理機構部１２の改修が発生した場合にも、実行ファイルの内容を修正するだけで、Ｐｏｄ１０に含まれる複数のアプリケーション管理機構部１２のバージョンの統一も容易に行えるようになる。すなわち、本実施形態によれば、アプリケーションの開発者が、複数のバージョンの共存を考慮した作り込み等を行う手間を省くことができる。
　また、上述した実施形態では、Ｐｏｄ管理コンテナ２も、コンテナホスト上に実行ファイルとして実装される。すなわち、Ｐｏｄ管理コンテナ２もコンテナイメージ上に記載されない。したがって、本実施形態によれば、Ｐｏｄ管理コンテナ２の改修が発生した場合にも、実行ファイルの内容を修正するだけで、コンテナホスト上で動作する複数のＰｏｄ管理コンテナ２のバージョンの統一も容易に行えるようになる。それゆえ、本実施形態によれば、アプリケーションの開発者が、複数のバージョンの共存を考慮した作り込み等を行う手間を省くことができる。
　さらに、上述した実施形態では、アプリ起動監視定義ファイルｆｃにおいて、複数のアプリケーションの起動順が規定される。そして、アプリケーション管理機構部１２のアプリケーション実行部１２１は、アプリ起動監視定義ファイルｆｃにおいて規定された複数のアプリケーションの起動順に従って、アプリケーションを順に起動させる。したがって、本実施形態によれば、アプリケーションの開発者が、アプリケーションの起動待ち合わせ処理の作り込み等を行う手間を省くことができる。
なお、上述した実施形態は本発明を分かりやすく説明するためにシステムの構成を詳細且つ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。図１及び図２において実線又は矢印で示した制御線又は情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
　また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
　１…アプリケーションコンテナ、２…Ｐｏｄ管理コンテナ、１０…Ｐｏｄ、１１…コンテナイメージ、１２…アプリケーション管理機構部、２０…マイクロサービス実行管理基盤部、２１…Ｐｏｄ内コンテナ監視部、２２…Ｐｏｄ内イベント受信部、３０…ＯＳイベント検出部、４０…ＯＳイベント監視部、５０…コンテナエンジン、６０…コンテナ実行基盤制御機構部、１００…制御サーバー、１２１…アプリケーション実行部、１２２…アプリケーション監視部、２０１…Ｐｏｄ監視部、２０２…システム内イベント管理部、５０１…Ｐｏｄコンテナ管理部、５０２…構成情報、５０３…コンテナ実行部、６０１…Ｐｏｄコンテナ登録部、６０２…Ｐｏｄ実行指示部

Claims (12)

  1. 　複数のアプリケーションの起動に関する設定、及び、前記アプリケーションの異常終了時に取るべき対処内容が記載されたアプリ起動監視定義ファイルと、
    　前記アプリ起動監視定義ファイルの記載内容に基づいて複数の前記アプリケーションを起動させ、起動した前記アプリケーションの終了を検知し、前記アプリケーションの異常終了時における対処を行うアプリケーション管理機構部と、を備え、
    　前記アプリケーション管理機構部は、前記アプリケーションが実行されるアプリケーションコンテナが起動されることにより前記アプリケーションコンテナにマウントされ、前記アプリケーションコンテナのエントリポイントプロセスとして起動される
    　仮想化システム。
  2. 　複数の前記アプリケーションコンテナの監視を行う管理コンテナをさらに備え、
    　前記管理コンテナは、複数の前記アプリケーションコンテナを含むＰｏｄの起動時に前記Ｐｏｄにマウントされ、前記Ｐｏｄのエントリポイントプロセスとして起動される
    　請求項１に記載の仮想化システム。
  3. 　前記アプリケーションコンテナの異常終了時に取るべき対処内容が定義されたＰｏｄ定義ファイルをさらに備え、
    　前記管理コンテナは、前記Ｐｏｄ定義ファイルに定義された対処内容に基づいて、前記アプリケーションコンテナの異常終了時の対処を行う
    　請求項２に記載の仮想化システム。
  4. 　前記アプリケーション管理機構部は、前記アプリケーションの異常終了をイベントとして前記管理コンテナに出力し、
    　前記管理コンテナは、前記イベントに記載された内容に基づいて、前記Ｐｏｄ定義ファイルを参照して、前記アプリケーションコンテナの異常終了時の対処を行う
    　請求項３に記載の仮想化システム。
  5. 　前記管理コンテナの監視、及び、前記管理コンテナから送信される前記イベントに記載された内容に基づいて、前記イベントに対する対処を行うサービス実行管理基盤部をさらに備え、
    　前記管理コンテナは、前記アプリケーション管理機構部から入力された前記イベントを前記サービス実行管理基盤部に転送する
    　請求項４に記載の仮想化システム。
  6. 　前記アプリケーションコンテナ、前記管理コンテナ及び前記Ｐｏｄが実行されるコンテナホストにおける異常発生の有無を監視して、検出した異常の内容を前記イベントとして前記サービス実行管理基盤部に出力するイベント監視部をさらに備える
    　請求項５に記載の仮想化システム。
  7. 　前記イベントは、前記イベントの識別子、前記イベントの種別の情報、及び、前記イベントの内容を示す文字列を含む
    　請求項６に記載の仮想化システム。
  8. 　前記イベントは、前記イベントに対する対処の緊急度を示すイベントレベルの情報をさらに含み、
    　前記サービス実行管理基盤部は、高い前記イベントレベルが付与された前記イベントに対する対処を優先的に行う
    　請求項７に記載の仮想化システム。
  9. 　前記アプリケーション管理機構部は、前記アプリケーションコンテナにマウントされる前において、前記コンテナホスト上に実行ファイルとして実装される
    　請求項８に記載の仮想化システム。
  10. 　前記管理コンテナは、前記Ｐｏｄにマウントされる前において、前記管理コンテナが起動するコンテナホスト上に実行ファイルとして実装される
    　請求項９に記載の仮想化システム。
  11. 　前記アプリ起動監視定義ファイルにおける複数の前記アプリケーションの起動に関する設定には、複数の前記アプリケーションの起動順が規定され、
    　前記アプリケーション管理機構部は、前記アプリ起動監視定義ファイルにおいて規定された複数の前記アプリケーションの起動順に従って、複数の前記アプリケーションを順に起動させる
    　請求項１０に記載の仮想化システム。
  12. 　複数のアプリケーションの起動に関する設定、及び、前記アプリケーションの異常終了時に取るべき対処内容が記載されたアプリ起動監視定義ファイルと、前記アプリ起動監視定義ファイルの記載内容に基づいて複数の前記アプリケーションを起動させ、起動した前記アプリケーションの終了を検知し、前記アプリケーションの異常終了時における対処を行うアプリケーション管理機構部と、を備えた仮想化システムの制御方法であって、
    　前記アプリケーション管理機構部が、前記アプリケーションが実行されるアプリケーションコンテナが起動されることにより前記アプリケーションコンテナにマウントされ、前記アプリケーションコンテナのエントリポイントプロセスとして起動される手順を含む
    　仮想化システムの制御方法。
PCT/JP2024/026971 2024-03-18 2024-07-29 仮想化システム及び仮想化システムの制御方法 Pending WO2025197136A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2024042493A JP2025142891A (ja) 2024-03-18 2024-03-18 仮想化システム及び仮想化システムの制御方法
JP2024-042493 2024-03-18

Publications (1)

Publication Number Publication Date
WO2025197136A1 true WO2025197136A1 (ja) 2025-09-25

Family

ID=97138520

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2024/026971 Pending WO2025197136A1 (ja) 2024-03-18 2024-07-29 仮想化システム及び仮想化システムの制御方法

Country Status (2)

Country Link
JP (1) JP2025142891A (ja)
WO (1) WO2025197136A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08328880A (ja) * 1995-05-31 1996-12-13 Mitsubishi Electric Corp 複数のアプリケーションプログラムを同時に実行できるオペレーティングシステムにおける計算機運転管理システム
US20210165876A1 (en) * 2017-11-22 2021-06-03 Aqua Security Software, Ltd. System for securing software containers with embedded agent
US20230318952A1 (en) * 2015-07-27 2023-10-05 Datagrid Systems Llc Method, apparatus and system for real-time optimization of computer-implemented application operations using machine learning techniques

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08328880A (ja) * 1995-05-31 1996-12-13 Mitsubishi Electric Corp 複数のアプリケーションプログラムを同時に実行できるオペレーティングシステムにおける計算機運転管理システム
US20230318952A1 (en) * 2015-07-27 2023-10-05 Datagrid Systems Llc Method, apparatus and system for real-time optimization of computer-implemented application operations using machine learning techniques
US20210165876A1 (en) * 2017-11-22 2021-06-03 Aqua Security Software, Ltd. System for securing software containers with embedded agent

Also Published As

Publication number Publication date
JP2025142891A (ja) 2025-10-01

Similar Documents

Publication Publication Date Title
US11157373B2 (en) Prioritized transfer of failure event log data
JP5128944B2 (ja) コンピュータアプリケーションにおけるデータ損失を最小限にする方法およびシステム
US7908521B2 (en) Process reflection
US7337365B2 (en) Platform for computer process monitoring
JP5579650B2 (ja) 監視対象プロセスを実行する装置及び方法
US7685474B2 (en) Failsafe computer support assistant using a support virtual machine
US7856639B2 (en) Monitoring and controlling applications executing in a computing node
US10379922B1 (en) Error recovery in a virtual machine-based development environment
US9558007B2 (en) Out-of band configuration of BIOS setting data
US7721153B2 (en) System, method and program product for recovering from a failure
US11507479B2 (en) High availability for a relational database management system as a service in a cloud platform
TWI261748B (en) Policy-based response to system errors occurring during OS runtime
WO2018095107A1 (zh) 一种bios程序的异常处理方法及装置
US10353729B1 (en) Managing service dependencies across virtual machines in a development environment
US20250147968A1 (en) Platform and service disruption avoidance using deployment metadata
JP5425720B2 (ja) 仮想化環境監視装置とその監視方法およびプログラム
JP5218394B2 (ja) グリッド処理制御装置
CN116627702A (zh) 虚拟机的宕机重启方法及装置
JP5387767B2 (ja) 実行中のプログラムの更新技術
CN114791900A (zh) 基于Operator的Redis运维方法、装置、系统及存储介质
US7934199B2 (en) Automated operation of IT resources with multiple choice configuration
JP2025142891A (ja) 仮想化システム及び仮想化システムの制御方法
US20240345844A1 (en) Cluster Management Method, Device, and Computing System
JP7389877B2 (ja) ネットワークの最適なブートパスの方法及びシステム
CN117931649A (zh) 一种操作系统死锁复位的测试方法及计算设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24930737

Country of ref document: EP

Kind code of ref document: A1