Device and method for automatically constructing system operation mechanism

Abstract

To provide a device for automatically constructing a system operation mechanism, that monitors a system, and generates configuration information of the system so as to generate a required recovery procedure according to a monitoring result.SOLUTION: Means for designing a fault tolerance mechanism generates configuration information of a system satisfying given system requirements, so as to satisfy conditions of generating a recovery procedure of each constituent comprised in the system, and generates a recovery procedure of a constituent in which a fault has occurred, when failure has occurred in any of the constituents. Means for generating a state monitoring procedure generates a state monitoring procedure that is a collection of concrete confirmation tasks for confirming a state of individual constituents comprised in the system. Fault corresponding means monitors the system by using the state monitoring procedure.SELECTED DRAWING: Figure 19

Description

[Technical Field]

[0001] The present disclosure relates to an automatic system operation mechanism construction device, an automatic system operation mechanism construction method, and an automatic system operation mechanism construction program. [Background technology]

[0002] The development of industry requires the active use of ICT (Information and Communication Technology) systems (hereafter simply referred to as systems).However, systems generally have complex configurations, and the difficulty of providing and operating them stably and quickly is an obstacle to the use of such systems.

[0003] To address this issue, Patent Document 1 discloses a technology that automatically builds a system configuration that meets requirements simply by providing those requirements, and then automatically operates the system to maintain that state. This technology includes a technology for automatically generating an operation plan based on the requirements, and a technology for automatic operation based on the operation plan. [Prior art documents] [Patent documents]

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

[0005] However, the technology disclosed in Patent Document 1 aims to adjust the amount of resources, such as computers and memory, included in the system in response to fluctuations in demand, such as system usage frequency and load, etc. Therefore, the technology disclosed in Patent Document 1 does not address work to recover from failures, such as breakdowns in equipment included in the system.

[0006] It is preferable to be able to generate system configuration information so that the system can be monitored and necessary recovery procedures can be generated depending on the monitoring results.

[0007] Therefore, the present disclosure aims to provide an automatic system operation mechanism construction device, an automatic system operation mechanism construction method, and an automatic system operation mechanism construction program that can generate system configuration information so as to monitor the system and generate necessary recovery procedures based on the monitoring results. [Means for solving the problem]

[0008] The system operation mechanism automatic construction device according to the present disclosure is characterized by comprising: a fault-tolerant configuration design means that generates configuration information for a system that satisfies given system requirements so as to satisfy the condition that recovery procedures can be generated for each component included in the system, and that, when a failure occurs in any of the components, generates a recovery procedure for the failed component; a status monitoring procedure generation means that generates a status monitoring procedure, which is a set of specific confirmation tasks for checking the status of each component included in the system; and a fault response means that monitors the system using the status monitoring procedure.

[0009] The method for automatically constructing a system operation mechanism according to the present disclosure is characterized in that a computer generates configuration information for a system that meets given system requirements in a manner that satisfies the condition that recovery procedures can be generated for each component included in the system, generates a status monitoring procedure that is a set of specific confirmation tasks for checking the status of each component included in the system, monitors the system using the status monitoring procedure, and, if a failure occurs in any of the components, generates a recovery procedure for the component in which the failure occurred.

[0010] The system operation mechanism automatic construction program disclosed herein causes a computer to execute a fault-tolerant configuration design process that generates system configuration information that satisfies given system requirements so as to satisfy the condition that recovery procedures can be generated for each component included in the system, a status monitoring procedure generation process that generates a status monitoring procedure that is a set of specific confirmation tasks for checking the status of each component included in the system, a fault response process that monitors the system using the status monitoring procedure, and a recovery procedure generation process that generates a recovery procedure for a component that has failed when a fault occurs in one of the components. [Effects of the Invention]

[0011] According to the present invention, it is possible to generate system configuration information so that a system can be monitored and necessary recovery procedures can be generated according to the monitoring results. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a block diagram illustrating a configuration example of a system operation mechanism automatic construction device according to the present disclosure. [Figure 2] FIG. 2 is an explanatory diagram illustrating an example of system configuration information. [Figure 3] FIG. 10 is an explanatory diagram showing a recovery procedure. [Figure 4] FIG. 10 is an explanatory diagram showing an example of a specific recovery procedure. [Figure 5] FIG. 10 is an explanatory diagram showing an example of definition of an agent and its method. [Figure 6] FIG. 10 is an explanatory diagram illustrating an example of system requirements. [Figure 7] FIG. 10 is an explanatory diagram showing an example of a state monitoring procedure. [Figure 8] 10 is a flowchart showing an outline of the processing flow when a system requirement is input. [Figure 9] 10 is a flowchart showing an outline of the process flow of the system operation mechanism automatic construction device when the constructed system is in operation. [Figure 10] FIG. 10 is an explanatory diagram illustrating an example of a component type model. [Figure 11] FIG. 10 is an explanatory diagram illustrating an example of a state element. [Figure 12] FIG. 10 is an explanatory diagram showing an example of a description of an expected configuration in an AP Server type component model. [Figure 13] 1 is a graph illustrating an example of a state transition system. [Figure 14] FIG. 10 is an explanatory diagram illustrating an example of a task described in a state element. [Figure 15] FIG. 10 is an explanatory diagram illustrating an example of a status check task described in a status element. [Figure 16] 10 is a graph schematically illustrating an example of a specific implementation of the configuration information proposal. [Figure 17] This is a graph in which the dependency relationships between the components included in the configuration information are expressed by dotted arrows. [Figure 18] FIG. 2 is a schematic block diagram illustrating an example of the configuration of a computer related to a system operation mechanism automatic construction device. [Figure 19] 1 is a block diagram showing an overview of a system operation mechanism automatic construction device according to the present disclosure; [Figure 20] 10 is a graph showing an example of a system configuration to which an agent has been added. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, embodiments according to the present disclosure will be described with reference to the drawings.

[0014] 1 is a block diagram showing an example configuration of a system operation mechanism automatic construction device according to the present disclosure. The system operation mechanism automatic construction device 100 according to the present disclosure includes an integrated control unit 110, a storage unit 120, a fault-tolerant configuration design unit 130, a specific confirmation task generation unit 140, a status monitoring procedure generation unit 150, a fault response unit 160, and a recovery procedure execution unit 170. The integrated control unit 110 is connected to an external input / output device (not shown) so as to be able to communicate with it.

[0015] The integrated control unit 110 provides the user with an automatic system design function and an automatic system operation function via an input / output device.

[0016] Specifically, the integrated control unit 110 accepts system requirements for the system that the user wants to build. Then, the integrated control unit 110 causes the fault-tolerant configuration design unit 130 to generate system configuration information that satisfies the system requirements and recovery procedures for each component included in the system. The integrated control unit 110 also causes the specific confirmation task generation unit 140 to generate specific confirmation tasks. The specific confirmation tasks are tasks for checking the status of individual components included in the system, and are generated for each component. The integrated control unit 110 also causes the status monitoring procedure generation unit 150 to generate a status monitoring procedure, which is a collection of specific confirmation tasks. Furthermore, the integrated control unit 110 generates a system ID for the system, associates the system configuration information, status monitoring procedure, and system ID, and stores them in the storage unit 120. The integrated control unit 110 then outputs the system ID to the user.

[0017] The integrated control unit 110 also receives from the user the system ID of the system that the user wants to operate, and reads out the configuration information and status monitoring procedure associated with that system ID from the storage unit 120. The integrated control unit 110 then causes the fault response unit 160 to monitor the status of the system using the status monitoring procedure, and if a fault (e.g., a breakdown) occurs, causes the fault-tolerant configuration design unit 130 to generate a recovery procedure for the component in which the failure occurred. The integrated control unit 110 then causes the recovery procedure execution unit 170 to execute the recovery procedure.

[0018] The storage unit 120 is a storage device that stores system configuration information, a status monitoring procedure, and a system ID in association with each other. The storage unit 120 also stores in advance a component type model for each component of the system and a status element for each component. The component type model and the status element will be described later.

[0019] The fault-tolerant configuration design unit 130 receives system requirements and generates configuration information for a system that satisfies the system requirements, so as to satisfy the condition that recovery procedures for each component included in the system can be generated.

[0020] Furthermore, if a failure occurs in any of the components, the fault-tolerant configuration design unit 130 generates a recovery procedure for the component in which the failure occurred.

[0021] The fault-tolerant configuration design unit 130 and the like acquire the component type models and state elements required for operation from the storage unit 120 via the integrated control unit 110.

[0022] The specific confirmation task generation unit 140 generates specific confirmation tasks for each component included in the system using the system configuration information, the component type model, and the state elements.

[0023] The status monitoring procedure generator 150 uses the system configuration information, each specific check task, and the component type model to generate a status monitoring procedure, which is a set of specific check tasks.

[0024] The failure response unit 160 receives a status monitoring procedure, monitors the system using the status monitoring procedure, and if an abnormal state is detected, identifies the component in which the failure occurred.

[0025] The restoration procedure execution unit 170 receives a restoration procedure, executes the restoration procedure, and restores the failed component, thereby restoring the system.

[0026] The integrated control unit 110, the fault-tolerant configuration design unit 130, the specific confirmation task generation unit 140, the status monitoring procedure generation unit 150, the fault response unit 160, and the recovery procedure execution unit 170 are realized, for example, by a CPU (Central Processing Unit) of a computer that operates in accordance with a system operation mechanism automatic construction program. In this case, the CPU reads the system operation mechanism automatic construction program from a program recording medium such as a program storage device of the computer, and operates as the integrated control unit 110, the fault-tolerant configuration design unit 130, the specific confirmation task generation unit 140, the status monitoring procedure generation unit 150, the fault response unit 160, and the recovery procedure execution unit 170 in accordance with the system operation mechanism automatic construction program.

[0027] The storage unit 120 is realized by, for example, a storage device provided in the computer.

[0028] Next, a description will be given of data etc. generated by the system operation mechanism automatic construction device 100. The component type model and state elements stored in advance in the storage unit 120 will be described later together with an explanation of the operation.

[0029] Figure 2 is an explanatory diagram showing an example of system configuration information. Figure 2(A) is an example of system configuration information, and Figure 2(B) is a graph visually expressing the system configuration represented by the configuration information. As shown in Figure 2(A), the system configuration information is written in text.

[0030] A graph representing a system configuration (see Figure 2(B)) contains nodes and edges. Nodes represent the parts that make up the system, and are called component parts. Edges represent the relationships between component parts, and are called relationships. Component parts and relationships are collectively called components.

[0031] Each component has at least an ID and a type that indicates the type of the component. However, in this specification, relationship IDs are omitted. In addition to the ID and type, each component may have additional information such as properties.

[0032] In the graph shown in Figure 2(B), the circles represent component parts, and the arrows connecting the circles represent relationships. The labels attached to the component parts indicate the type and id, with the type shown to the left of the colon ":" and the id shown to the right of the colon. In some cases, either or both of the type and id may be omitted as appropriate. An icon corresponding to the type type is shown inside the circle representing the component part.

[0033] The configuration information shown in Fig. 2(A) is written in YAML (Yet Another Markup Language) format. The configuration information includes a "configuration" (see Fig. 2(A)).

[0034] The "Configuration" field lists the IDs of the components included in the system. In the example shown in Figure 2(A), IDs such as "app1" and "aps1" are listed. Information about each component is then described as an attribute of each ID. Specifically, a "Type" and a "Relationship" are described for each ID. The "Type" is the type of the component. The "Relationship" is the relationship from one component to another. The "Relationship" is expressed as an array. The "Type" and "Destination" of the relationship are described as attributes of each relationship. The "Type" of a relationship consists of a pair of a base type, which is the type of the relationship itself, and a double-ended type, which is the type of the components at both ends. For example, if HostedOn(WebApp, APServer) is described, HostedOn is the base type, and WebApp and APServer are double-ended types.

[0035] The "connection destination" field contains the ID of the component part with which the relationship is established, written in reference format. The reference format is a string with "$" appended to the ID string, which indicates that it is referencing another element.

[0036] The configuration information shown in FIG. 2(A) includes six components: "app1", "aps1", "rdb1", "sv1", "sv2", and "sw1". Taking "app1" as an example, the type of the component with an id of "app1" is WebApp. This component has a HostedOn(WebApp, APServer) type relationship with "aps1" as the connection destination, and an AccessDB(WebApp, RDB) type relationship with "rdb1" as the connection destination.

[0037] The configuration information is the output for the system requirements, which corresponds to the input to the system operation mechanism automatic construction device. The configuration information represents the system configuration. The method for describing the system requirements is the same as the method for describing the configuration information.

[0038] Fig. 3 is an explanatory diagram showing the recovery procedure. However, the specific recovery procedure is not described in Fig. 3. As shown in Fig. 3, the recovery procedure is described for each ID of a component.

[0039] FIG. 4 is an explanatory diagram showing an example of a specific recovery procedure. FIG. 4 illustrates a recovery procedure when a failure (for example, a breakdown) occurs in a Server-type component (hereinafter referred to as Server:sv1) whose id is "sv1" in the configuration information shown in FIG. 2. That is, of the recovery procedures omitted from FIG. 3, the recovery procedure shown in FIG. 4 is described as the recovery procedure corresponding to "sv1". Below, an example will be explained in which the failure is a breakdown.

[0040] A recovery procedure is a set of multiple ordered tasks. Each task in a recovery procedure is described by id, agent, method, parameters, and depends. id is the identifier of the task with that id. agent is the id of the entity that executes that task. method is the work that the agent performs. parameters are the arguments given to method. depends indicates the id of other tasks that should be executed beforehand. Therefore, depends is omitted for the first task.

[0041] The agents and methods that can be described in the recovery procedure are predefined. In the example shown in Figure 4, agents called cloudAgent and ansibleAgent appear. Methods such as deleteVM, createVM, and bootVM are called for cloudAgent. Methods such as installPackage, runService, pullFile, and reloadService are called for ansibleAgent. These methods are defined in advance along with the agents.

[0042] Figure 5 is an explanatory diagram showing an example of the definition of an agent and its method. Figure 5 also shows an example of a cloudAgent and its method. Figure 5 also shows an example of the contents of deleteVM. The command description in Figure 5 represents the command actually executed by the OS (Operating System). The {{vm_id}} part is where the vm_id value defined in the parameters shown in Figure 4 is inserted. The command description often contains a complex and lengthy command sequence (character string). As shown in Figure 5, by defining an agent and its method, the actual complex execution content can be shared and hidden. As a result, the recovery procedure can concisely describe the tasks to be performed, avoiding the need to write specific and detailed commands each time.

[0043] The first task shown in Figure 4 is a task with id "sv1.F->A#1". This task causes the agent with id "cloudAgent1" to execute the method "deleteVM". When this method is executed, the string "sv1" is given to deleteVM as the value of the argument named vm_id. Because this task is the first task, "depends" is omitted.

[0044] The second task listed in Figure 4 is the task with id "sv1.A->C#2". Since "sv1.F->A#1" is written in the depends of this task, this second task will be executed after the task with id "sv1.F->A#1".

[0045] A recovery procedure describes a series of tasks required to restore the entire system to a normal state when a certain component fails. For example, the recovery procedure shown in Figure 4 is the recovery procedure to be performed when Server:sv1 in the configuration information shown in Figure 2 fails. If Server:sv1 fails, APServer:aps1, which depends on Server:sv1, and WebApp:app1, which depends on APServer:aps1, will stop in a chain reaction, so the recovery procedure shown in Figure 4 also includes operations to restore APServer:aps1 and WebApp:app1.

[0046] Figure 6 is an explanatory diagram showing an example of system requirements. As mentioned above, the method for describing system requirements is the same as the method for describing configuration information. Therefore, system requirements can be considered a form of configuration information. However, unlike generated configuration information, system requirements do not need to specifically describe all of the components necessary for operation. System requirements only need to describe the necessary parts at a sufficient level of abstraction. The example shown in Figure 6 simply requires that a web application be run, so it shows a system requirement that includes only one WebApp-type component.

[0047] Figure 7 is an explanatory diagram showing an example of a status monitoring procedure. A status monitoring procedure is a set of ordered specific confirmation tasks. A component that needs to be monitored regularly is called a regular monitoring target. The status monitoring procedure includes a specific confirmation task (called the first specific confirmation task) for checking the status of the regular monitoring target, and a specific confirmation task (called the second specific confirmation task) for identifying the component that has failed if the regular monitoring target enters an abnormal state. The description specifications for the status monitoring procedure are almost the same as those for the recovery procedure. However, in the status monitoring procedure, the ID of the component whose status should be confirmed is described as the ID. In addition, in the status monitoring procedure, each specific confirmation task includes criteria. The criteria are information that links the execution result of the method with the state of the component. The criteria link the message obtained as the execution result to each character string that indicates the possible states of the target component (in the example shown in Figure 7, "A", "C", "H", and "F") (see Figure 7). However, the method described in the status monitoring procedure returns a message as the execution result.

[0048] For example, the first specific confirmation task shown in Figure 7 is a specific confirmation task that monitors the status of "app1". In this specific confirmation task, the method "serviceStatus" of the agent with the id "ansibleAgent1" is executed with two arguments, url: "http: / / xxx.xxx / app1" and name: "app1". Then, the status of "app1" is determined based on the returned message. Specifically, if the obtained message is "none", the status of "app1" is determined to be "A". If the obtained message is "deployed", the status of "app1" is determined to be "C". If the obtained message is "http_ok", the status of "app1" is determined to be "H". If the obtained message is "error", the status of "app1" is determined to be "F".

[0049] Of the specific confirmation tasks included in the status monitoring procedure, the one that does not have a depends clause is the first specific confirmation task. The specific confirmation task that has depends is the second specific confirmation task. The second specific confirmation task is executed after the other specific confirmation tasks described in its depends clause have been executed. The second specific confirmation tasks are executed sequentially according to the depends clause, and the component that is determined to be in an abnormal state immediately before the component that is determined to be in a normal state is determined to be the component where the failure occurred.

[0050] Next, an outline of the processing flow will be shown. After describing the outline of the processing flow, detailed operations will be explained. Figure 8 is a flowchart showing an outline of the processing flow when system requirements are input.

[0051] When a system requirement is input by a user via an input / output device (not shown) (step S11), the integrated control unit 110 accepts the system requirement and sends it to the fault-tolerant configuration design unit .

[0052] The fault-tolerant configuration design unit 130 generates configuration information for a system that satisfies the system requirements, so that recovery procedures can be generated for each component included in the system (step S12). At this time, the fault-tolerant configuration design unit 130 sets the configuration information representing the system requirements as the initial state of the configuration information. The fault-tolerant configuration design unit 130 then generates the configuration information by repeatedly instantiating the configuration information one step at a time and selecting, from the configuration information proposals obtained by the instantiation, configuration information proposals that can be used to generate recovery procedures for each component included in the proposed configuration information. Therefore, the fault-tolerant configuration design unit 130 also generates recovery procedures for each component in step S12.

[0053] Furthermore, if new components are added as the configuration information is specified, the fault-tolerant configuration design unit 130 determines the ID of the added component, identifies the type and relationship of the added component, and generates a draft of the configuration information by describing the ID, type, and relationship in the configuration information.

[0054] The fault-tolerant configuration design unit 130 returns the generated configuration information to the integrated control unit 110. The integrated control unit 110 sends the configuration information generated in step S12 to the specific confirmation task generation unit 140.

[0055] The specific confirmation task generator 140 generates a specific confirmation task for each component included in the configuration information (step S13), and returns each specific confirmation task to the integrated control unit 110.

[0056] The integrated control unit 110 sends the configuration information generated in step S12 and each specific check task to the status monitoring procedure generation unit 150.

[0057] The state monitoring procedure generator 150 generates a state monitoring procedure that is a set of ordered specific check tasks (step S14). At this time, the state monitoring procedure generator 150 generates a state monitoring procedure that includes a first specific check task and a second specific check task.

[0058] The status monitoring procedure generator 150 returns the generated status monitoring procedure to the integrated control unit 110.

[0059] The integrated control unit 110 generates a system ID for the system represented by the configuration information (step S15). Then, the integrated control unit 110 associates the configuration information generated in step S12 with the status monitoring procedure and the system ID, and stores them in the storage unit 120 (step S16).

[0060] Then, the integrated control unit 110 returns the system ID to the user via the input / output device (step S17).

[0061] The above is an overview of the process when system requirements are entered. After the above process, the system represented by the configuration information is constructed. This system can be constructed manually or automatically.

[0062] FIG. 9 is a flowchart showing an outline of the process flow of the system operation mechanism automatic construction device when the constructed system is in operation.

[0063] When a user inputs the system ID of a system that the user wants to operate via an input / output device (not shown) (step S21), the integrated control unit 110 accepts the system ID. The integrated control unit 110 then reads out the status monitoring procedure associated with the system ID from the storage unit 120 and sends the status monitoring procedure to the failure response unit 160.

[0064] The failure response unit 160 checks the status of the routinely monitored object in accordance with the status monitoring procedure (step S22). The failure response unit 160 checks the status of the routinely monitored object in accordance with a specific confirmation task that does not have "depends" among the specific confirmation tasks included in the status monitoring procedure (i.e., the first specific confirmation task).

[0065] If the status of the steady-state monitoring target is normal (No in step S23), the failure handler 160 waits for a certain period of time and then executes step S22 again.

[0066] If the state of the steady-state monitoring target is abnormal (Yes in step S23), the failure response unit 160 identifies the component in which the failure occurred according to the state monitoring procedure (step S24). At this time, the failure response unit 160 identifies the component in which the failure occurred according to a second specific confirmation task included in the state monitoring procedure. More specifically, the failure response unit 160 executes the second specific confirmation task sequentially according to the description in depends, and identifies the component determined to be in an abnormal state immediately before the component determined to be in a normal state as the component in which the failure occurred.

[0067] The failure response unit 160 sends the system ID and the ID of the component in which the failure occurred to the fault-tolerant configuration design unit 130 via the integrated control unit 110.

[0068] The fault-tolerant configuration design unit 130 again generates a recovery procedure for when a component identified by the above component ID fails in the monitored system (step S25).

[0069] The fault-tolerant configuration design unit 130 sends the restoration procedure to the restoration procedure execution unit 170 via the integrated control unit 110 .

[0070] The restoration procedure execution unit 170 executes the restoration procedure to restore the failed component, thereby restoring the system (step S26).

[0071] After step S26, the operations from step S22 onwards are repeated.

[0072] As described above, a recovery procedure is generated for each component in step S12. However, because the overall amount of data for the recovery procedures for each component is large, it may not be appropriate to associate the recovery procedure for each component with a system ID and store it in the storage unit 120. Therefore, in this embodiment, the recovery procedure generated together with the configuration information in step S12 is not stored in the storage unit 120, and instead, when a component in which a failure has occurred is identified, the fault-tolerant configuration design unit 130 regenerates a recovery procedure corresponding to that component.

[0073] If there is no problem in storing all of the recovery procedures for each component element generated in step S12 in the storage unit 120, the integrated control unit 110 may, in step S16, associate the configuration information, the recovery procedure, the status monitoring procedure, and the system ID, and store them in the storage unit 120. In this case, it is not necessary to execute step 25, and the recovery procedure execution unit 170 may simply obtain, via the integrated control unit 110, the recovery procedure corresponding to the ID of the component element in which the failure occurred, and execute that recovery procedure.

[0074] Next, step S12 will be described in detail. The fault-tolerant configuration design unit 130 receives the system requirements and generates specific configuration information. At this time, the fault-tolerant configuration design unit 130 generates the configuration information so that all of the components included in the configuration information have recovery procedures.

[0075] The basic operation for generating concrete configuration information from system requirements is a search process that sets the system requirements as the initial state and the concrete configuration information as the target state. The fault-tolerant configuration design unit 130 generates multiple candidate configuration information proposals by concretizing the current proposed configuration information one step at a time. The fault-tolerant configuration design unit 130 repeatedly evaluates the validity of the generated configuration proposals and selects the most appropriate proposed configuration information. A single concretization step involves either replacing the type of each component included in the proposed configuration information with a more specific type or complementing one of the expected configurations. When all components included in the proposed configuration information have concrete types and the expected configurations are complemented, the proposed configuration information is considered concrete. Information on whether a component's type is concrete and the expected configuration of that type are described in the component type model for that component.

[0076] FIG. 10 is an explanatory diagram showing an example of a component type model. FIG. 10(A) is an example of a component type model, and FIG. 10(B) is a graph showing the expected configuration described in the configuration information type model. The component type model is described in text as shown in FIG. 10(A). FIG. 10 shows an example of a WebApp type component type model. A component type model is created in advance for each component part.

[0077] A component type model has a component type (WebApp in the example shown in Figure 10(A)), an inheritance source, a concreteness flag, properties, and an expected configuration. In the example shown in Figure 10(A), the line from "base" to the last line represents one expected configuration. "base" is the name of the expected configuration and can be a string other than "base".

[0078] Each component type can inherit from another component type by specifying the name of that type as the inheritance source. By inheriting from another component type, a component type inherits the information of the inheritance source, and then extends or overwrites it by adding only the parts that differ from the type information of the inheritance source. The inherited type is called a derived type, an extended type, etc., and is considered to be a type of the inheritance source type.

[0079] The concreteness flag is a flag that indicates whether the type is a concrete type.

[0080] A property is information that represents an attribute value that the type can hold.

[0081] An expected configuration is a peripheral configuration that must be satisfied for a component of a certain type to establish specific configuration information. For example, a WebApp-type component (see Figure 10(A)) must be connected to an APServer-type component via a HostedOn(WebApp, APServer) relationship, and a WebApp-type component must be connected to an RDB-type component via an AccessDB(WebApp, RDB) relationship. Furthermore, the APServer-type component must be connected to an RDB-type component via a ConnTo(APServer, RDB) relationship. Such conditions that a component requires of its peripheral configuration are specified as an expected configuration. Note that a single component-type model can include multiple expected configurations, but this specification does not address examples of expected configuration-type models that include two or more expected configurations.

[0082] As mentioned above, in the example shown in Figure 10(A), the lines from "base" to the last line represent one expected configuration. Figure 10(B) visually represents this one expected configuration. The expected configuration is expressed as a partial configuration that includes the component type itself that requires the expected configuration. In the expected configuration graph shown in Figure 10(B), the component itself that requires the expected configuration is represented by a double-lined circle.

[0083] As mentioned above, one component-based model can include multiple expected configurations, but this specification does not address examples of expected configuration-based models that include two or more expected configurations. Therefore, in this specification, the expected configurations included in one component-based model are represented by a single graph, as shown in Figure 10(B).

[0084] In addition, in the component type model (see, for example, FIG. 10(A)), the two-end types of the relationship type are appropriately omitted.

[0085] The component type model shown in Figure 10(A) describes the "inheritance source," "concreteness flag," "properties," and "expected configuration." Since one component type model can contain multiple expected configurations, the name of the expected configuration is described first, followed by information about that expected configuration. As mentioned above, in the component type model shown in Figure 10(A), "base" is the name of the expected configuration. Then, after the name of the expected configuration, the contents of the expected configuration are described in the same description format as the configuration information. However, the ID of the type itself that requests the expected configuration is described as $self, a special reference format.

[0086] Note that when the types at both ends of a relationship type are abbreviated with "_", the types of the components at both ends specified in the component type model will be substituted for the abbreviated part. For example, in the component type model shown in Figure 10(A), the first relationship that $self has, "HostedOn(_, _)", has $self as the source and $aps as the destination. Because $self is described as being of type WebApp itself and the type of $aps is APServer (see Figure 10(A)), the formal type name of this relationship is interpreted as HostedOn(WebApp, APServer).

[0087] To generate configuration information that ensures that all components have recovery procedures, the fault-tolerant configuration design unit 130 searches for specific configuration information proposals while rejecting configuration information proposals for which recovery procedures cannot be generated. That is, the fault-tolerant configuration design unit 130 evaluates the validity of the configuration information proposals generated in one stage of instantiation from the perspective of whether recovery procedures can be generated for each component included in the configuration information proposals, and selects configuration information proposals for which recovery procedures can be generated for each component. Therefore, once the fault-tolerant configuration design unit 130 generates configuration information proposals, it attempts to generate recovery procedures for each component included in the configuration information proposals and selects configuration information proposals for which recovery procedures can be generated for each component.

[0088] The fault-tolerant configuration design unit 130 generates state transition system information before generating a recovery procedure. The state transition system information is necessary for generating a recovery procedure. The state transition system information is generated by linking it to configuration information (proposed configuration information). In one stage of instantiation of the proposed configuration information, the fault-tolerant configuration design unit 130 adds components to the proposed configuration information by complementing the proposed configuration information before instantiation with an expected configuration. Next, the fault-tolerant configuration design unit 130 adds information about the state elements of the added components to the state transition system linked to the proposed configuration information before instantiation, thereby generating a state transition system linked to the proposed configuration information after instantiation. For example, suppose that configuration plan Q is generated by adding component A to configuration plan P. In this case, the fault-tolerant configuration design unit 130 adds the state element of component A to the state transition system linked to configuration plan P, thereby generating a state transition system linked to configuration plan Q.

[0089] Here, a state element is information that compiles a set of possible states of a certain component or possible state transitions. Also, a state transition system is information that links multiple state elements with dependencies between them.

[0090] Fig. 11 is an explanatory diagram showing an example of a status element. Fig. 11 shows an example of an APServer type status element. A status element is created in advance for each component part.

[0091] A state element has a "type that has this state element" and a "state element" (see Figure 11). The "type that has this state element" is the type of the component corresponding to the state element. The "state element" indicates the content of the state element. A "state element" has a "state" and a "state check task." Multiple states are listed in the "state." The "state check task" describes the task for checking the state of the component corresponding to the state element in a format that includes a reference. Each state is described with a string representing the state's ID, and its contents include a "transition" and a "dependency source transition" (see Figure 11). The "transition" describes the destination states to which the current state can transition, and each destination state defines a "dependency destination state" and a "task." The "dependency destination state" describes the states of other components that must be satisfied when the transition is executed. The "task" describes a recovery task, described later, in a format that includes a reference. The "dependency source transition" describes the transition within another component that depends on the current state. Here, A depends on B means that A needs B.

[0092] When describing other components in "dependency destination state" or "dependency source transition", they are described in reference format as shown in Figure 11. In this case, the other components are described so as to reference the components listed in the expected configuration indicated by the component type model corresponding to the type (APServer type in the example in Figure 11) that has a state element that includes "dependency destination state" or "dependency source transition". The same applies when referencing other components within a "task" or "status check task" included in a state element.

[0093] For example, Figure 11 contains the description "$sv.F->A." Figure 11 shows the state element of APServer. The above "$sv.F->A" expresses the transition from state F to state A in the Server-type component. Here, the Server-type component for APServer corresponds to, for example, "sv1" for "aps1" shown in Figure 2. Therefore, the component model of APServer type includes the description of the expected configuration shown in Figure 12. As with referencing sv in Figure 12, other components are described in reference format in the "dependency state" and "dependency source transition."

[0094] In the example of the state element shown in Figure 11, four states are defined: "A", "C", "H", and "F". State "A" has a transition to state "C". The transition from state "A" to state "C" depends on state "H" of component $sv. In other words, to transition from state "A" to state "C", component $sv must be in state "H". Furthermore, state "A" is dependent on the transition from state "F" to state "A" of component $sv and the transition from state "C" to "A". In other words, for component $sv to transition from state "F" to state "A", or for component $sv to transition from state "C" to "A", the APServer state must be "A".

[0095] Figure 13 shows a state transition system with the same content as Figure 11. Each rectangle in Figure 13 represents one state element. Each ellipse represents a state, solid arrows between ellipses represent transitions, and dotted arrows between transitions and states represent dependencies.

[0096] FIG. 11 shows the state element of APServer, and in the component-type model of APServer, Server:sv is entered as the expected configuration (see FIG. 12). Therefore, when completing the expected configuration, the fault-tolerant configuration design unit 130 adds Server to the proposed configuration information. When completing the state transition system in accordance with this addition, the fault-tolerant configuration design unit 130 adds the state element of Server to the state transition system, and adds the dependency between APServer and Server to the state transition system. As a result, when focusing only on APServer and Server, the state transition system shown in FIG. 13 is obtained. The dependency between state elements indicated by the state element of Server is added to the state transition system when Server is instantiated.

[0097] The fault-tolerant configuration design unit 130 uses the generated state transition system to generate a recovery procedure for each component. Japanese Patent Application Publication No. 2015-215885 (hereinafter referred to as Reference 1) describes a method for calculating possible state transition procedures from a certain current state to a specific destination state in a state transition system such as the one described above. The fault-tolerant configuration design unit 130 generates a state transition procedure that moves the states of all state elements from the current state to the destination state without violating the dependencies between the state elements, for example, using the method described in Reference 1. However, the method for generating the state transition procedure is not limited to the method described in Reference 1 and may be other methods.

[0098] The fault-tolerant configuration design unit 130 determines the current state and target state when generating a recovery procedure for a component as follows: The fault-tolerant configuration design unit 130 determines the current state as a state in which the component of interest is in a failed state (here, "F") and all other components in the proposed configuration information are in a normal state (here, "H"). The fault-tolerant configuration design unit 130 also determines the target state as a state in which all components included in the proposed configuration information are in a normal state (here, "H"). The fault-tolerant configuration design unit 130 then generates a state transition procedure from the current state to the target state. The fault-tolerant configuration design unit 130 generates a state transition procedure for each component included in the proposed configuration information as described above. However, when generating a recovery procedure in step S25 (see FIG. 9), it is sufficient to generate a state transition procedure as described above only for the component that has failed. The process of generating a state transition procedure and then generating a recovery procedure is common to steps S12 and S25. The fault-tolerant configuration design unit 130 generates one recovery procedure based on one state transition procedure.

[0099] The normal state and fault state of each component are defined in advance. In this embodiment, for simplicity of explanation, it is assumed that all state elements have a state "H" and a state "F." "H" is the normal state, and "F" is the fault state. However, it may be possible to define various specific states as the normal state and the fault state for each component.

[0100] The fault-tolerant configuration design unit 130 generates a recovery procedure from one state transition procedure by the following process: By generating the transition procedure, for example, the following state transition procedure information is obtained. (1) Change the state of $sv from A to C. (2) Change the state of $aps1 from A to C. (3) Change the state of $app1 from A to C.

[0101] In the state element (see FIG. 11), one task (recovery task) is described for one transition. In other words, one task (recovery task) is associated with one transition. An example of a task (recovery task) omitted in FIG. 11 is shown in FIG. 14.

[0102] The fault-tolerant configuration design unit 130 replaces transitions with tasks (such as the tasks shown in FIG. 14) in the order indicated by the state transition procedure information. At this time, the tasks contain reference formats. When replacing transitions with tasks, the fault-tolerant configuration design unit 130 concretely describes the reference format sections within the tasks. The fault-tolerant configuration design unit 130 references the expected configuration of the component-type model that corresponds to the type of state element that includes the task, identifies the section corresponding to that expected configuration from the configuration information, and inserts the concrete information described in that section into the reference format within the task, thereby concretely specifying the task.

[0103] Furthermore, the fault-tolerant configuration design unit 130 adds a depends indicating the ID of the previous task to each task from the second onwards, resulting in a recovery procedure of the format shown in FIG.

[0104] The fault-tolerant configuration design unit 130 then discards any configuration proposals that include components for which recovery procedures cannot be obtained, and selects configuration proposals for which recovery procedures can be obtained for all components.The fault-tolerant configuration design unit 130 then re-specifies the selected configuration proposals one step and performs the same processing.By repeating this operation, in step S12, configuration information is generated that satisfies the condition that recovery procedures can be generated for each component.

[0105] In the above explanation, step S25 was also mentioned, but in step S25, fault-tolerant configuration design unit 130 may end the process at the point when it has generated a recovery procedure for the component in which the failure occurred.

[0106] The recovery procedure and generation of configuration information in step S12 have been described above.

[0107] Next, the generation of the specific confirmation task in step S13 will be described.

[0108] The specific confirmation task generation unit 140 generates a specific confirmation task for each component included in the configuration information. A specific confirmation task is a task that embodies the status confirmation task (see FIG. 11) described in the status element of each type. An example of the status confirmation task omitted in FIG. 11 is shown in FIG. 15. The status confirmation task is described in a status element created in advance for each component, and the status confirmation task is linked to the component.

[0109] The specific confirmation task generation unit 140 extracts a corresponding state confirmation task for each component included in the configuration information and generates the specific confirmation task by replacing the reference format in the state confirmation task with specific information. The specific confirmation task generation unit 140 references the expected configuration of the component type model corresponding to the type of state element including the state confirmation task, identifies a portion of the configuration information corresponding to the expected configuration, and inserts the specific information described in that portion into the reference format in the state confirmation task, thereby concretizing the state confirmation task. As a result, a specific confirmation task is obtained.

[0110] The status check task differs from the task (recovery task) illustrated in Fig. 14 in that it includes criteria information. Other than this, the description format is common between the status check task and the task illustrated in Fig. 14.

[0111] Next, the generation of the status monitoring procedure in step S14 will be described. The status monitoring procedure generator 150 generates the status monitoring procedure based on information in a graph format formed by the reference relationships of the expected configurations. First, the information in a graph format formed by the reference relationships of the expected configurations will be described.

[0112] Figure 16 is a graph that shows a schematic example of the instantiation of a proposed configuration. Figure 16 shows a schematic representation of a proposed configuration. Consider the case where the system requirements shown in (a) are input. In this case, (a) contains only one WebApp-type component. Therefore, by applying the expected configuration defined in the WebApp-type component model to that component, the proposed configuration shown in (b) is generated. In reality, multiple proposed configurations may be generated, and one proposed configuration is selected from among them. However, in this example, only (b) is generated, and (b) is selected. Next, for each of the components included in the proposed configuration (b) that can be instantiated, applicable instantiations are applied to generate multiple proposed configurations, and one appropriate proposed configuration is selected from among them. Here, the proposed configuration shown in (c) is selected.

[0113] Here, the proposed configuration information shown in (b) is obtained by applying an expected configuration that includes an APServer type component, an RDB type component, and the relationship connecting the two, to the WebApp type component in the proposed configuration information shown in (a).The proposed configuration information shown in (c) is obtained by applying an expected configuration that includes a Server type component and the relationship connecting the APServer type component and the Server type component to the APServer type component in the proposed configuration information shown in (b).

[0114] By the way, there exists a dependency relationship between a certain component and a component included in the expected configuration of that component, in which the former depends on the latter. When component A depends on component B, it means that component B is necessary for component A to exist.

[0115] In the example shown in FIG. 16, there is a dependency relationship in which a WebApp type component depends on an APServer type component and an RDB type component, and the APServer type component depends on a Server type component.

[0116] 17 is a graph in which the dependency relationships between the components included in the configuration information are expressed by dotted arrows. Information connecting the components with dependency relationships is expressed in graph format.

[0117] The status monitoring procedure generation unit 150 generates a status monitoring procedure by converting the above-mentioned graph-format information (for example, FIG. 17) in which the components are connected by dependency relationships, as follows. That is, the status monitoring procedure generation unit 150 replaces the components in the graph with specific confirmation tasks, and replaces the dependency relationships between the components with the execution order relationships between the specific confirmation tasks. Specifically, if component A depends on component B, the status monitoring procedure generation unit 150 writes the ID of the specific confirmation task of component A in the depends of the specific confirmation task of component B. As a result, in the generated status monitoring procedure, the specific confirmation task of component B is executed after the status check task of component A is executed.

[0118] Furthermore, the state monitoring procedure generator 150 does not write "depends" in a specific check task that has been replaced by a component that is not dependent on by other components.

[0119] Of the specific confirmation tasks included in the status monitoring procedure, the specific confirmation task that does not have a depends description is the first specific confirmation task, and the specific confirmation task that has a depends description is the second specific confirmation task.

[0120] The generation of the status monitoring procedure in step S14 has been described above.

[0121] In step S22 of FIG. 9, the failure response unit 160 checks the status of the steady-state monitoring target in accordance with the first specific confirmation task among the specific confirmation tasks included in the status monitoring procedure.

[0122] 9, if it is determined that the state of a certain component is abnormal, the fault response unit 160 executes one or more specific confirmation tasks that depend on the specific confirmation task of the component determined to be in the abnormal state. In other words, the fault response unit 160 executes one or more specific confirmation tasks that describe in their depends the ID of the specific confirmation task of the component determined to be in the abnormal state. If any of these components is determined to be in an abnormal state, the fault response unit 160 similarly executes one or more specific confirmation tasks that depend on the specific confirmation task of the component determined to be in the abnormal state. By repeating this operation, the fault response unit 160 identifies the component in which a failure has occurred (step S24).

[0123] For example, suppose that an abnormal state is obtained as a result of executing a specific confirmation task on a WebApp. In this case, the fault response unit 160 executes the specific confirmation task on the APServer and the RDB. Then, for example, if the execution result of the specific confirmation task on the APServer is an abnormal state, the fault response unit 160 executes the specific confirmation task on the Server that hosts the APServer. If the Server's state is normal, the fault response unit 160 determines that a fault has occurred in the APServer. In this way, the component in which the fault has occurred is identified.

[0124] After step S24, the fault-tolerant configuration design unit 130 generates a recovery procedure for the component in which the failure has occurred (step S25).

[0125] Then, the restoration procedure execution unit 170 restores the failed component in accordance with the restoration procedure, thereby restoring the system (step S26).

[0126] According to the present disclosure, system configuration information can be generated to satisfy the condition that recovery procedures for each component included in the system can be generated simply by inputting system requirements. Therefore, system configuration information can be generated so that the system can be monitored and necessary recovery procedures can be generated according to the monitoring results.

[0127] Furthermore, the failure response unit 160 checks the status of the object to be monitored according to a first specific confirmation task included in the status monitoring means, and when the status of the object to be monitored becomes abnormal, identifies the component in which the failure has occurred according to a second specific confirmation task, thereby reducing the load of the monitoring process.

[0128] In the above embodiment, an agent is shown as the entity that executes tasks in the recovery procedure and status monitoring procedure. For example, two agent instances, "ansibleAgent1" and "cloudAgent1," appear in the recovery procedure illustrated in FIG. 4 and the status monitoring procedure illustrated in FIG. 7. These agent instances may appear as components in the proposed configuration information. In the above example, a component with an ID of "ansibleAgent1" and a component with an ID of "cloudAgent1" appear in the proposed configuration information. The process by which an agent appears in the proposed configuration information is similar to the process by which other components appear in the proposed configuration information. In other words, an agent is added to the proposed configuration information when it is included in the expected configuration of another component. Figure 20 shows a graph illustrating an example of a system configuration to which an agent has been added.

[0129] 18 is a schematic block diagram showing an example of the configuration of a computer related to a system operation mechanism automatic construction device. The computer 2000 includes, for example, a CPU 2001, a main memory device 2002, an auxiliary memory device 2003, and an interface 2004.

[0130] The system operation mechanism automatic construction device according to the present disclosure is realized, for example, by a computer 2000. The operation of the system operation mechanism automatic construction device is stored in the form of a program (system operation mechanism automatic construction program) in an auxiliary storage device 2003. A CPU 2001 reads the program from the auxiliary storage device 2003, loads the program into a main storage device 2002, and executes the processing described in the above embodiment in accordance with the program.

[0131] The auxiliary storage device 2003 is an example of a non-transitory tangible medium. Other examples of non-transitory tangible media include a magnetic disk, a magneto-optical disk, a CD-ROM (Compact Disk Read Only Memory), a DVD-ROM (Digital Versatile Disk Read Only Memory), and a semiconductor memory connected via the interface 2004.

[0132] Next, an overview of the system operation mechanism automatic construction device according to the present disclosure will be described. Fig. 19 is a block diagram showing an overview of the system operation mechanism automatic construction device according to the present disclosure. The system operation mechanism automatic construction device includes fault-tolerant configuration design means 71, status monitoring procedure generation means 72, and fault response means 73.

[0133] The fault-tolerant configuration design means 71 (for example, the fault-tolerant configuration design unit 130) generates configuration information for a system that satisfies given system requirements so as to satisfy the condition that recovery procedures can be generated for each component included in the system, and when a failure occurs in any of the components, generates a recovery procedure for the component in which the failure occurred.

[0134] The status monitoring procedure generating means 72 (for example, the status monitoring procedure generating unit 150) generates a status monitoring procedure, which is a set of specific check tasks for checking the status of each component included in the system.

[0135] The fault handling means 73 (for example, the fault handling unit 160) uses a status monitoring procedure to monitor the system.

[0136] Such a configuration allows the system to be monitored and system configuration information to be generated so that necessary recovery procedures can be generated depending on the monitoring results.

[0137] The above-described embodiment of the present invention can also be described as follows, but is not limited to the following.

[0138] (Appendix 1) a fault-tolerant configuration design means for generating system configuration information that satisfies given system requirements so as to satisfy the condition that a recovery procedure for each component included in the system can be generated, and for generating a recovery procedure for the component in which a failure occurs when a failure occurs in any of the components; a status monitoring procedure generation means for generating a status monitoring procedure which is a set of specific confirmation tasks for confirming the status of each component included in the system; a fault response means for monitoring the system using the status monitoring procedure. A system operation mechanism automatic construction device characterized by:

[0139] (Appendix 2) and a recovery procedure execution means for recovering the system by recovering the failed component using the generated recovery procedure. 2. The system operation mechanism automatic construction device according to claim 1.

[0140] (Appendix 3) The status monitoring procedure generation means generating a status monitoring means including a first specific confirmation task for confirming the status of a regular monitoring target, which is a component that should be regularly monitored, and a second specific confirmation task for identifying the component in which a failure has occurred when the regular monitoring target goes into an abnormal state; The failure response means includes: When the routinely monitored object goes into an abnormal state, the component in which the failure occurred is identified according to the second specific confirmation task. 2. The system operation mechanism automatic construction device according to claim 1.

[0141] (Appendix 4) The fault-tolerant configuration design means The configuration information representing the system requirements is used as the initial state of the configuration information, and the configuration information is instantiated in one step. From the configuration information proposals obtained by the instantiation, a configuration information proposal that can generate a recovery procedure for each component included in the configuration information proposal is selected and the configuration information is generated by repeating this process. 4. A system operation mechanism automatic construction device according to any one of appendix 1 to appendix 3.

[0142] (Appendix 5) The computer generating configuration information for a system that satisfies given system requirements, so as to satisfy the condition that recovery procedures for each component included in the system can be generated; generating a status monitoring procedure which is a set of specific confirmation tasks for confirming the status of each component included in the system; monitoring the system using the condition monitoring procedure; When a failure occurs in any of the components, a recovery procedure for the component in which the failure occurs is generated. A system operation mechanism automatic construction method characterized by:

[0143] (Appendix 6) On the computer, A fault-tolerant configuration design process for generating system configuration information that satisfies given system requirements so as to satisfy the condition that recovery procedures for each component included in the system can be generated; a status monitoring procedure generation process for generating a status monitoring procedure, which is a set of specific confirmation tasks for checking the status of each component included in the system; a fault response process that monitors the system using the status monitoring procedure; and A recovery procedure generation process for generating a recovery procedure for a component in which a failure occurs when a failure occurs in any of the components. An automatic system operation mechanism construction program for executing the above.

[0144] Some or all of the configurations described in Supplementary Notes 2 to 4, which are dependent on Supplementary Note 1, may also be dependent on Supplementary Notes 5 and 6 in the same dependent relationship as Supplementary Notes 2 to 4. Furthermore, not limited to Supplementary Notes 1, 5, and 6, some or all of the configurations described as Supplements may be made dependent on various hardware, software, various recording means for recording software, or systems, within the scope of the above-described embodiment.

[0145] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure. [Industrial Applicability]

[0146] The present disclosure is suitably applied to a system operation mechanism automatic construction device that generates system configuration information and monitors the system. [Explanation of symbols]

[0147] 100 System operation mechanism automatic construction device 110 Integrated control unit 120 Storage section 130 Fault Tolerant Configuration Design Department 140 Specific confirmation task generation unit 150 Status monitoring procedure generation unit 160 Disability Response Department 170 Recovery Procedure Execution Department

Claims

1. a fault-tolerant configuration design means for generating system configuration information that satisfies given system requirements so as to satisfy the condition that a recovery procedure for each component included in the system can be generated, and for generating a recovery procedure for the component in which a failure occurs when a failure occurs in any of the components; a status monitoring procedure generation means for generating a status monitoring procedure which is a set of specific confirmation tasks for confirming the status of each component included in the system; a fault response means for monitoring the system using the status monitoring procedure. A system operation mechanism automatic construction device characterized by:

2. and a recovery procedure execution means for recovering the system by recovering the failed component using the generated recovery procedure.

2. The system operation mechanism automatic construction device according to claim 1.

3. The status monitoring procedure generation means generating a status monitoring means including a first specific confirmation task for confirming the status of a regular monitoring target, which is a component that should be regularly monitored, and a second specific confirmation task for identifying the component in which a failure has occurred when the regular monitoring target goes into an abnormal state; The failure response means includes: When the routinely monitored object goes into an abnormal state, the component in which the failure occurred is identified according to the second specific confirmation task.

2. The system operation mechanism automatic construction device according to claim 1.

4. The fault-tolerant configuration design means The configuration information representing the system requirements is used as the initial state of the configuration information, and the configuration information is instantiated in one step. From the configuration information proposals obtained by the instantiation, a configuration information proposal that can generate a recovery procedure for each component included in the configuration information proposal is selected and the configuration information is generated by repeating this process.

4. The system operation mechanism automatic construction device according to claim 1.

5. The computer generating configuration information for a system that satisfies given system requirements, so as to satisfy the condition that recovery procedures for each component included in the system can be generated; generating a status monitoring procedure which is a set of specific confirmation tasks for confirming the status of each component included in the system; monitoring the system using the condition monitoring procedure; When a failure occurs in any of the components, a recovery procedure for the component in which the failure occurs is generated. A system operation mechanism automatic construction method characterized by:

6. On the computer, A fault-tolerant configuration design process for generating system configuration information that satisfies given system requirements so as to satisfy the condition that recovery procedures for each component included in the system can be generated; a status monitoring procedure generation process for generating a status monitoring procedure, which is a set of specific confirmation tasks for checking the status of each component included in the system; a fault response process that monitors the system using the status monitoring procedure; and A recovery procedure generation process for generating a recovery procedure for a component in which a failure occurs when a failure occurs in any of the components. An automatic system operation mechanism construction program for executing the above.

Images