JP2020005138A - Inference device of failure influence range, inference device of failure cause, inference method and program of failure cause - Google Patents

Abstract

To provide an inference method of failure cause not requiring to calculate all failure propagation paths previously, and capable of automatic refining of the failure cause.SOLUTION: When failure information about an element constituting a network is inputted, an inference method selects an element having impact on the state from a preserved dependence rule, detects state propagation rule on the basis of the selected element, estimates the range of the elements receiving impact of the failure information, and when failure state about the network is inputted, selects one or more elements relevant to the failure state from the dependence rule, retrieves one or more states which the selected element can take, detects the state propagation rule on the basis of the selected element and the retrieved state, and performs cause estimation for estimating a list of the elements becoming the cause of fault state and the state of the elements.SELECTED DRAWING: Figure 1

Description

  The present disclosure relates to a fault influence range and a fault cause inference method using a network ontology.

  The network configuration has become complicated due to server and network virtualization technologies. In a large-scale dynamic system, it is difficult for a network administrator to accurately grasp the entire system, and the cost of locating the cause and the scope of the failure is increasing. As a result, there is a growing demand for automation of fault cause inference.

  Non-Patent Document 1 applies a general-purpose analysis rule to an IT system configuration modeled by ontology and infers a root cause of a failure. One general-purpose analysis rule includes a condition part and a conclusion part. The condition specified by the condition part specifies the type of the IT device and the resource that configures the device, and the type of event generated from the resource. In the conclusion part, the type of the device, the type of the resource, and the type of the event generated from the resource are described as a result of the analysis. By defining in this way, the general-purpose analysis rule can describe a condition for the topology, and can describe a co-occurrence condition of a failure event.

  Non-Patent Document 2 expresses a method of transmitting abnormal information between system components in an ontology. This method uses two types of rules: a rule for deriving a dependency and a rule for state propagation. In the case of the influence range inference, it is possible to find a component affected by expanding a rule in order from a component causing a cause and propagating a state. In the case of fault cause inference, all dependencies and state propagation rules are expanded, and all paths through which abnormal conditions propagate in the system are calculated. Then, by extracting only the path including the currently occurring fault state, the constituent elements of the cause candidates can be listed.

Patent No. 5845133

Hiroshi Kudo, Tomohiro Morimura, Kiminori Sugauchi, Tetsuya Masuishi, Norihisa Shinoda. Rule construction method and analysis execution method for failure cause analysis. IEICE Transactions C, Vol. 132, no. 10, pp. 1689-1697, 2012. H. Dihowski, O .; Holub, and J.M. Rojcek. Knowledge-Based Fault Propagation in Building Automation System. In Proceedings of 2016 International Conference on Systems Information, Modeling and Simulation (SIMS), pp. 147-64. 124-132, June 2016. Kei Mikami, Shinji Kawaguchi, Ryota Oshima, Kenta Shimamatsu, Kenro Kondo, Osamu Kamagai, Osamu Akashi, Shincho Kaneko, Fumio Teraoka. A study on network management method using network ontology Bonsai. IEICE Technical Report, IN2006-86), January 2017. Shinji Kawaguchi, "KANVAS: An Open Information Sharing Platform Using Ontologies for Utilizing Network Knowledge," Master's Thesis, Graduate School of Science and Engineering, Keio University, March 2016.

  The method of Non-Patent Document 1 targets only failure cause inference and does not consider failure influence range inference. In the method of Non-Patent Document 2, fault cause inference and fault influence range inference are realized, but for that purpose, all rules need to be developed in advance according to the system configuration. For this reason, according to the method of Non-Patent Document 2, when the system to be analyzed becomes large-scale and complicated, the number of components and the number of inference rules increase, so that it is difficult to calculate a fault propagation path in advance. There was a first problem.

  In addition, although any of the methods described in the literatures can infer the cause of a failure, it is necessary to manually verify the indicated cause candidate, and there is a second problem that it is difficult to narrow down the cause of the failure.

In order to solve the first problem, the present invention provides a fault influence range inference apparatus that does not need to calculate all fault propagation paths in advance even if the system to be analyzed becomes large-scale and complicated. It is an object to provide a failure cause inference device, a failure influence range inference method, a failure cause inference method, and a program.
Another object of the present invention is to provide a failure cause inference apparatus, a failure cause inference method, and a program capable of automatically narrowing down a failure cause in order to solve the second problem. .

  In order to achieve the above object, the apparatus and method for estimating the scope of a failure according to the present invention develops and holds dependency rules and state propagation rules according to network configuration information.

Specifically, the fault inference range inference device according to the present invention includes:
A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. Setting means for setting a propagation rule;
Storage means for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When failure information on the element is input, select the element that has an effect on the state from the stored dependency rules, detect the state propagation rule based on the selected element, Range estimating means for estimating the range of the element affected by the failure information;
Is provided.

In addition, the method of inferring the range of failure influence according to the present invention is as follows.
A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. A setting procedure for setting a propagation rule,
A storage procedure for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When failure information on the element is input, select the element that has an effect on the state from the stored dependency rules, detect the state propagation rule based on the selected element, A range estimation procedure for estimating the range of the element affected by the failure information,
I do.

  The fault influence range inference device according to the present invention may further include a failure information response unit that makes a response to the input failure information an influence on a network service in the estimated range of the element.

On the other hand, the fault cause inference device according to the present invention includes:
A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. Setting means for setting a propagation rule;
Storage means for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When a fault condition for the network is input, one or more of the elements related to the fault condition are selected from the stored dependency rules, and one or more of the selected elements can be taken. The state estimation rule is searched based on the selected element and the searched state to detect the state propagation rule, and the cause estimation for estimating the list of the element causing the failure state and the state of the element is performed. Means for estimating the cause
Is provided.

In addition, the method of inferring the cause of the fault according to the present invention includes:
A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. A setting procedure for setting a propagation rule,
A storage procedure for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When a fault condition for the network is input, one or more of the elements related to the fault condition are selected from the stored dependency rules, and one or more of the selected elements can be taken. A state estimating step of detecting the state propagation rule based on the selected element and the searched state, and estimating a list of the element causing the failure state and the state of the element When,
I do.

  The method for inferring the scope of the failure and the method for inferring the cause of the failure periodically collect the structure of the target network and deploy and hold only the dependency rules and state propagation rules according to the change in the structure. I have. For this reason, it is not necessary to calculate all the fault propagation paths in advance. Therefore, the present invention provides a failure influence range inference device, a failure cause inference device, and a failure influence range that can eliminate the need to calculate all failure propagation paths in advance even if the system to be analyzed becomes large-scale and complicated. An inference method and a failure cause inference method can be provided.

  The fault cause inference apparatus according to the present invention causes the cause estimating means to perform the cause estimation by assuming another fault situation similar to the fault situation, and the element causing the other fault situation and the Failure state response means for estimating another list of element states and removing a result common to the list and the items common to the other list from the list as a response to the input failure state may be further provided. Good.

  The fault cause inference apparatus estimates the cause based on the assumed failure state, and automatically narrows down the cause of the failure by comparing with the current cause estimation. Therefore, the present invention can provide a fault cause inference apparatus and a fault cause inference method capable of automatically narrowing down a fault cause.

  A program according to the present invention is a program for causing a computer to function as the failure influence range inference device or the failure cause inference device. The fault influence range inference device and the fault cause inference device according to the present invention can also be realized by a computer and a program, and the program can be recorded on a recording medium or provided through a network.

The present invention provides a failure influence range inference device, a failure cause inference device, and a failure influence range inference method that do not need to calculate all the failure propagation paths in advance even if the system to be analyzed becomes large-scale and complicated. , A failure cause inference method, and a program can be provided.
Further, the present invention can also provide a failure cause inference device, a failure cause inference method, and a program capable of automatically narrowing down a failure cause.

FIG. 2 is a block diagram illustrating a failure influence range inference device and a failure cause inference device according to the present invention. FIG. 1 is a configuration diagram illustrating an overall structure of a network ontology Bonsai. FIG. 2 is a diagram illustrating an example of a network at an IP level. FIG. 2 is an instance diagram illustrating an IP network configuration. FIG. 2 is a diagram illustrating an example of a network at a physical level. FIG. 2 is an instance diagram illustrating a physical network configuration. FIG. 3 is an instance diagram illustrating a network service configuration. FIG. 3 is a diagram illustrating an instance expression in a physical network configuration of a switch 3; FIG. 4 is a diagram illustrating an instance expression in a physical network configuration of an upstream interface of a switch. FIG. 3 is a diagram illustrating an instance expression in a physical network configuration of a link between a router 3 and a switch 3. FIG. 3 is a diagram illustrating an instance expression in a physical network configuration of a link between a switch 3 and a host 2; FIG. 4 is a diagram illustrating an instance expression in a logical network configuration of a link between a router 3 and a switch 3. FIG. 3 is a diagram illustrating an instance representation of subnet 3 in an IP network configuration. FIG. 3 is a diagram illustrating an instance expression of a communication path from a host 2 to a Web server. FIG. 3 is a diagram illustrating an instance expression in a host 3 IP network configuration. FIG. 3 is a diagram illustrating an instance expression in a host 3 IP network configuration. FIG. 3 is a diagram illustrating an instance expression of a web service in a network service configuration. It is a figure explaining the dependency relationship rule 1 (PhysicalNode-> PhysicalInterface). It is a figure explaining the dependency relationship rule 2 (PhysicalInterface-> PhysicalLink). It is a figure explaining the dependency relationship rule 3 (PhysicalLink-> LogicalLink). It is a figure explaining the dependency relationship rule 4 (LogicalLink-> IPSubnet). FIG. 9 is a diagram for explaining dependency rule 5 (IPSubnet-> IPPath). FIG. 9 is a diagram for describing dependency rule 6 (IPPath-> NetworkService). It is a figure explaining the state propagation rule 1 (PhysicalNode-> PhysicalInterface). It is a figure explaining the state propagation rule 2 (PhysicalInterface-> PhysicalLink). It is a figure explaining the state propagation rule 3 (PhysicalLink-> LogicalLink). It is a figure explaining the state propagation rule 4 (LogicalLink-> IPSubnet). It is a figure explaining the state propagation rule 5 (IPSubnet-> IPPath). It is a figure explaining the state propagation rule 6 (IPPath-> NetworkService). FIG. 9 is a diagram illustrating an instance expression in a physical network configuration of a switch 3 after application of a dependency relationship rule. FIG. 14 is a diagram illustrating an instance expression in a physical network configuration of an upstream interface of a switch after application of a dependency relationship rule. FIG. 9 is a diagram illustrating an instance expression in a physical network configuration of a link between a router 3 and a switch 3 after applying a dependency relationship rule. FIG. 9 is a diagram illustrating an instance expression in a logical network configuration of a link between a router 3 and a switch 3 after application of a dependency relationship rule. FIG. 11 is a diagram illustrating an instance expression of subnet 3 in an IP network configuration after applying a dependency relationship rule. FIG. 9 is a diagram illustrating an instance expression of a communication path from the host 2 to the Web server after applying the dependency relationship rule. It is a figure explaining the inference method of the fault influence range concerning the present invention. It is a figure explaining an influence range inference rule. FIG. 6 is a diagram illustrating a method of inferring a failure cause according to the present invention. It is a figure explaining a cause reasoning rule (1). It is a figure explaining a cause reasoning rule (2-1). It is a figure explaining a cause reasoning rule (2-2). It is a figure explaining a cause reasoning rule (3). FIG. 5 is a diagram illustrating an example of a FaultNode class used in the method of inferring a cause of a failure according to the present invention. FIG. 7 is a diagram illustrating an example of narrowing down a cause in the method of inferring a cause of a failure according to the present invention. FIG. 7 is a diagram illustrating a cause narrowing down procedure in the failure cause inference method according to the present invention. It is a figure explaining a narrowing rule of a fault tree. 1 shows an example of an overview of a KANVAS architecture. 1 shows an example of the internal structure of a KIG. 1 shows an example of an IP network configuration. 1 shows an example of a physical network configuration. 1 shows an example of a flowchart of a network configuration detection method. An example of the network configuration obtained after step S102 is shown. An example of the network configuration obtained after the end of step S103 is shown. An example of the network configuration obtained after the end of step S104 is shown. An example of the network configuration obtained after the end of step S105 is shown. An example of a network configuration obtained after the end of step S106 is shown.

  Embodiments of the present invention will be described with reference to the accompanying drawings. The embodiment described below is an example of the present invention, and the present invention is not limited to the following embodiment. In the specification and the drawings, components having the same reference numerals indicate the same components.

The inference device of the present embodiment is:
A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. Setting means for setting a propagation rule;
Storage means for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When failure information on the element is input, select the element that has an effect on the state from the stored dependency rules, detect the state propagation rule based on the selected element, Range estimating means for estimating the range of the element affected by the failure information; and / or when a failure situation for the network is input, one or more related to the failure situation from the stored dependency rules. Selecting a plurality of the elements, searching for one or more possible states of the selected elements, detecting the state propagation rule based on the selected elements and the searched states, Cause estimating means for estimating the cause of the situation and estimating a list of the state of the element and the state of the element;
It is characterized by having.
Note that the above “elements” refer to nodes, interfaces, links, routes, subnets, services, and the like that constitute a network.

1. Module Configuration FIG. 1 shows a block diagram of the inference apparatus. The network configuration information collection module 11 automatically collects network configuration information, converts it into an instance representation based on the network ontology Bonsai, and stores it in a network configuration information RDF (Resource Description Framework) storage. A specific example of the network configuration information collection module 11 will be described later.

  Bonsai is a domain ontology based on RDF and OWL (Web Ontology Language) (Non-Patent Document 3). FIG. 2 shows the overall image of the network configuration ontology by Bonsai. Bonsai is composed of five layers and six categories. The first layer defines a physical network configuration, the second layer defines a logical network configuration, the third layer defines an IP network configuration, the fourth layer defines an overlay network configuration, and the fifth layer defines a network service configuration and an operation network configuration. The network configuration information collection module 11 stores the network configuration information in the network configuration information RDF storage 21 each time a change in the network configuration is detected.

  The rule input module 25 converts the dependency relation rule and the state propagation rule defined by the system administrator into the SPIN (SPARQL Inferring Notation) format, and stores them in the SPIN dependency relation rule storage 22 and the SPIN state propagation rule storage 24.

  When detecting a change in the information stored in the network configuration information RDF storage 21, the SPIN inference engine 12 applies the SPIN dependency relationship rule to the network configuration information, and stores the result in the dependency rule expansion storage 23.

  The input / output module 26 is a module serving as an interface for receiving failure information from the system user and returning an inference result to the user. There are the following two types of fault information. One is information that specifies a fault location in the network (fault specifying information). For example, information such as "the network switch 1 has failed". The other is information describing a failure status (failure status information). For example, it is information such as “the web server cannot be browsed from the host 1”.

  Upon receiving the failure designation information from the input / output module 26, the influence range inference module 13 converts the failure designation information into a representation format based on Bonsai and inquires the dependency relationship rule storage 23 to determine the range affected by the failure. Infer. At this time, the result of temporarily applying the dependency relationship rule is stored in the temporary dependency rule expansion storage 27.

  Upon receiving the failure status information from the input / output module 26, the failure cause inference module 14 inquires the dependency relationship expansion storage 23 and infers the cause of the failure by reversing the dependency from the failure status, thereby inferring the tree structure. Obtain the cause of failure. At this time, the result of temporarily applying the state propagation rule is stored in the temporary state propagation storage 28.

  The setting means corresponds to the SPIN inference engine 12, the rule input module 25, the SPIN dependency relation rule storage 22, and the SPIN state propagation rule storage 24. The storage means corresponds to the network configuration information collection module 11, the SPIN inference engine 12, the network configuration information RDF storage 21, and the dependency relationship expansion storage 23. The range estimating means corresponds to the SPIN inference engine 12, the influence range inference module 13, the input / output module 26, the dependency rule expansion storage 23, and the temporary dependency rule expansion storage 27. The cause estimating means corresponds to the SPIN inference engine 12, the failure cause inference module 14, the dependency rule expansion storage 23, and the temporary state propagation storage 28.

The inference apparatus of the present embodiment causes the cause estimating means to perform the cause estimation by assuming another failure situation similar to the failure situation, and the element causing the other failure situation and the state of the element The apparatus further includes a failure status response unit that estimates another list, and removes an item common to the list and the other list from the list as a response to the input failure status.
The failure situation response means is a failure cause narrowing down module 15, which narrows down the failure cause from a plurality of failure cause candidates inferred from a plurality of failure situation information.

2. Network Configuration Example FIG. 3 shows an IP-level configuration of a network used as an example in this specification. FIG. 4 is a diagram showing an IP network configuration of this network as an instance based on Bonsai. FIG. 5 shows the configuration of the physical level of this network. FIG. 6 is a diagram showing the physical network configuration of this network as an instance based on Bonsai. FIG. 7 is a diagram showing a network service configuration of the web server 1 operating on the host 3 as an instance based on Bonsai. Instance diagrams relating to the logical network configuration, the overlay network configuration, and the operation network configuration are omitted.

  FIG. 8 shows an instance expression in the physical network configuration of the switch 3. The name of this instance is switch3_p. FIG. 9 shows an instance expression in the physical network configuration of the upstream interface of the switch 3. The name of this instance is if_s3_u_p. FIG. 10 shows an instance representation of a link between the router 3 and the switch 3 in the physical network. The name of this instance is link_r3s3_p. FIG. 11 shows an instance representation of a link between the switch 3 and the host 2 in the physical network. The name of this instance is link_s3h2_p. FIG. 12 shows an instance representation of a link between the router 3 and the switch 3 in a logical network. The name of this instance is link_r3s3_1. FIG. 13 shows an instance expression in the IP network configuration of the IP subnet 3. The name of this instance is subnet3_i. FIG. 14 shows an instance expression of an IP route between the host 2 and the web server 1 in the IP network configuration. The name of this instance is path_h2w1_i. FIG. 15 shows an instance expression of the host 3 in the IP network configuration. The name of this instance is host3_i. FIG. 16 shows an instance expression in the service network configuration of the host 3. The name of this instance is host3_s. FIG. 17 shows an instance expression in the service network configuration of the web server 1. The name of this instance is web1_s.

3. Dependency Rules and State Propagation Rules A dependency rule describes two elements that are influencing each other (in a dependent relationship). For example, the SPIN dependency relationship rule shown in FIG. 18 indicates that when a physical interface is connected to a physical node, the state of the physical node affects the state of the physical interface. The SPIN dependency relation rule shown in FIG. 19 indicates that when a physical link is connected to a physical interface, the state of the physical interface affects the state of the physical link. The SPIN dependency relation rule shown in FIG. 20 indicates that the state of the physical link affects the state of the logical link when the logical link operates on the physical link. The SPIN dependency relation rule shown in FIG. 21 indicates that when the IP subnet operates on the logical link, the state of the logical link affects the state of the IP subnet. The SPIN dependency relation rule shown in FIG. 22 indicates that when an IP route is configured by an IP subnet, the status of the IP subnet affects the status of the IP route. The SPIN dependency relationship rule shown in FIG. 23 indicates that when a service is operating on a logical node that is an end point of an IP route, the status of the IP route affects the status of the service.

  The state propagation rule describes a specific state content that affects between two elements described in the dependency relationship rule. For example, according to the SPIN state propagation rule shown in FIG. 24, when a physical node has a state of “NodeDown” and there is a dependency between the physical node and the physical interface, the state of “IfDown” propagates to the physical interface. Is shown. The SPIN state propagation rule shown in FIG. 25 indicates that when a physical interface has a state of “IfDown” and there is a dependency between the physical interface and the physical link, a state of “LinkDown” propagates to the physical link. ing. The SPIN state propagation rule shown in FIG. 26 indicates that when a physical link has a state of “Link Down” and there is a dependency between the physical link and the logical link, a state of “Link Down” propagates to the logical link. ing. The SPIN state propagation rule shown in FIG. 27 indicates that the state “NetDown” propagates to the IP subnet when the logical link has the state “LikeDown” and there is a dependency between the logical link and the IP subnet. ing. The SPIN state propagation rule shown in FIG. 28 indicates that when an IP subnet has a state of “NetDown” and there is a dependency between this IP subnet and an IP path, a state of “Unreachable” propagates to the IP path. ing. The SPIN state propagation rule shown in FIG. 29 indicates that when the IP route has a state of “Unreachable” and there is a dependency between the IP route and the network service, the state of “Unavailable” propagates to the network service. ing.

4. Rule Expansion of Dependency In the present inference apparatus shown in FIG. 1, it is assumed that the SPIN dependency storage shown in FIGS. 18 to 23 has already been stored in the SPIN dependency storage. At this time, it is assumed that the network configuration information shown in FIGS. 8 to 17 has been input to the network configuration information RDF storage 21. Then, the SPIN inference engine 12 applies the SPIN dependency relation rule to the input network configuration information, and stores the result in the dependency rule development storage 23. The instance expression shown in FIG. 8 is rewritten as shown in FIG. 30 by the SPIN dependency relationship rule shown in FIG. 18 and the instance expression shown in FIG. In this example, the seventh and eighth lines are added to the original instance expression. The instance expression shown in FIG. 9 is rewritten as shown in FIG. 31 by the SPIN dependency relationship rule shown in FIG. 19 and the instance expression shown in FIG. 10 and FIG. In this example, the seventh line is added to the original instance expression. The instance expression shown in FIG. 10 is rewritten as shown in FIG. 32 by the SPIN dependency relationship rule shown in FIG. 20 and the instance shown in FIG. In this example, the seventh line is added to the original instance expression. The instance expression shown in FIG. 12 is rewritten as shown in FIG. 33 by the SPIN dependency relationship rule shown in FIG. 21 and the instance expression shown in FIG. In this example, the eighth line is added to the original instance expression. The instance expression shown in FIG. 13 is rewritten as shown in FIG. 34 by the SPIN dependency relationship rule shown in FIG. 22 and the instance expression shown in FIG. In this example, the ninth line is added to the original instance expression. The instance expression shown in FIG. 14 is rewritten as shown in FIG. 35 by the SPIN dependency relationship rule shown in FIG. 23 and the instance expression shown in FIG. In this example, the seventh line is added to the original instance expression.

  As long as there is no change in the network configuration information, the inference apparatus waits for an input from the system user at the stage where the processing up to this point is completed.

5. Influence range inference The operation performed by the range estimation means of the inference device will be described. FIG. 36 shows a procedure for inferring the range of influence at the network service level when the switch 3 fails. FIG. 37 shows the influence range inference rules used at that time.

(Step 1) The input / output module 25 transmits a request for “a failure range of the network service level when the switch 3 has failed” to the influence range inference module 13.
(Step 2) The influence range inference module 13 converts this information into the failure information triple “switch3_p−hasState−“ NodeDown ”” and transmits it to the dependency relationship rule storage 23.
(Step 3) The dependency relationship expansion storage 23 sends the ontology update to the temporary dependency relationship expansion storage 27.
(Step 4) The temporary dependency rule expansion storage 27 sends an ontology update notification to the SPIN inference engine 12.
(Step 5) The SPIN inference engine 12 expands the SPIN state propagation rule based on the added failure information triple, and adds the resulting triple to the temporary dependency rule expansion storage 27. The triples added by the SPIN inference engine 12 are as follows.
-If_s3_u_p-hasState-"IfDown"
-Link_r3s2_p-hasState-"LinkDown"
-Link_r3s2_1-hasState-"LinkDown"
-Subnet3_i-hasState-"NetDown"
-Path_h2h3-hasState-"Unreachable"
-Web1_s-hasState-"Unavailable"
(Step 6) The temporary dependency rule expansion storage 27 sends a triple addition notification to the influence range inference module 13.
(Step 7) The influence range inference module 13 transmits a state change instance request to the temporary dependency rule expansion storage 27 in order to obtain an instance whose state has been changed by triple addition by the SPIN inference engine 12.
(Step 8) The temporary dependency rule expansion storage 27 sends the instance whose state has changed to the influence range inference module 13. The instances whose status has changed are as follows.
-Switch3_p-hasState-"NodeDown"
-If_s3_u_p-hasState-"IfDown"
-Link_r3s2_p-hasState-"LinkDown"
-Link_r3s2_1-hasState-"LinkDown"
-Subnet3_i-hasState-"NetDown"
-Path_h3h2-hasState-"Unreachable"
-Web1_s-hasState-"Unavailable"
(Step 9) The influence range inference module 13 sends a reset request to the temporary dependency rule expansion storage 27 to delete the triple added in Step 2.
(Step 10) The temporary dependency rule expansion storage 27 deletes the triple added in Step 2, and sends a reset response to the influence range inference module 13.
(Step 11) As a result, the influence at the network service level is “web1_s−hasState−“ Unavailable ””, so that the influence range inference module 13 returns a response that “web1 cannot be browsed” to the input / output module 26.

6. Failure cause inference The operation performed by the cause estimation means of the inference apparatus will be described. FIG. 38 shows a procedure for inferring a failure cause when web1 cannot be browsed from the host 2. The fault inference rules used at this time are shown in FIGS. FIG. 43 shows a FaultNode class used in this rule.

(Step 1) The input / output module 25 transmits to the failure cause inference module 14 the information that “web1 cannot be browsed from the host 2”.
(Step 2) The failure cause inference module 14 transmits a dependent instance request “? −hasCausalRelationship−web1_s” to the dependency rule expansion storage 23 to search for an instance having a dependency on the state of web1_s.
(Step 3) The dependency relationship rule expansion storage 23 transmits “host3_i-hasCausalRelationship-web1_s” to the failure cause inference module 14 as a dependency instance response.
(Step 4) The failure cause inference module 14 sends a state candidate request “host3_i-possibleStates-?” To the dependency-rule expansion storage 23 to obtain a state that the host3_i can take.
(Step 5) The dependency rule expansion storage 23, based on the instance expression of the host3_i shown in FIG. 15 and stored in the network configuration information RDF storage 21, uses “NodeDown” as a possible state of the host3_i and infers a failure cause as a state candidate response. Send to module 14.
(Step 6) When the host3_i becomes “NodeDown”, the failure cause inference module 14 checks the triple “host3_i−hasState−“ NodeDown ”” to check whether web1_s is in a state of “Unavailable”. It is transmitted to the dependency relationship expansion storage 23 as an assumed triple.
(Step 7) The dependency rule expansion storage 23 adds the assumed triple and sends an ontology update notification to the SPIN inference engine 12.
(Step 8) The SPIN inference engine 12 applies the SPIN state propagation rule to the added triple and obtains the triple "web1_s-hasState-" Unavailable ", and adds this to the temporary state propagation storage.
(Step 9) The temporary state propagation storage sends a triple addition notification to the failure cause inference module 14.
(Step 10) The fault cause inference module 14 transmits “? −hasState−?” To the temporary state propagation storage as a state update instance request in order to obtain the instance whose state has been updated.
(Step 11) The temporary state propagation storage transmits the following to the failure cause inference module 14 as the instance whose state has changed.
-Host3_i-hasState-"NodeDown"
-Web1_s-hasState-"Unavailable"
(Step 12) As a result, it can be seen that it is possible to make a transition from “host3_i-hasState-“ NodeDown ”” to “web1_s-hasState-“ Unavailable ””, so the failure cause inference module 14 makes the “host3_i-hasState-“ NodeDow ”. "Is a candidate for the cause of" web1_s-hasState- "Unavailable"". Next, the failure cause inference module 14 sends a reset request to the temporary state propagation storage to cancel the hypothetical triple added in step 6.
(Step 13) The temporary state propagation storage 28 erases the contents updated in steps 6 to 8, and sends a reset response to the failure cause inference module 14. If a plurality of state candidates are returned in step 5, steps 6 to 13 are repeated for each state. When a plurality of dependent instances are returned in step 3, steps 4 to 13 are repeated for each instance. As a result of the above processing, the cause candidate instance is determined. In this example, "host3_i-hasState-" NodeDown "". Next, the fault cause inference module 14 returns to step 2 to obtain the cause of the determined cause candidate instance “host3_i−hasState−“ NodeDown ””, and uses “? −hasCausalRelationship−host3_i” as a dependent instance request and stores the dependency rule expansion storage. 23. Thereafter, the above procedure is recursively repeated until no cause candidate instance can be obtained.
(Step 14) As a result, the influence range inference module 13 obtains the fault tree shown in FIG. 44- (b), and transmits this to the input / output module 26.

  In the above procedure, first, an instance having a direct dependency with the failure status input in steps 2 and 3 is obtained. Next, in steps 4 to 13, the instances having a dependency relationship are sequentially traced from the respective instances obtained above. Inside steps 4 to 13, first, in steps 4 and 5, a state that the instance can take is obtained. Next, in Steps 6 to 11, it is checked whether or not each of the states obtained as described above can transition to the input failure state. In this process, the state propagation rule is developed in step 8, and the developed result is deleted in steps 12 and 13. As described above, the state propagation rules are developed only for the instances and their states that have a dependency relationship with the input fault information, and the development results are deleted immediately after checking the results. This reduces the memory consumption during execution.

7. The operation performed by the fault situation response means of the inference apparatus will be described. It is assumed that the host 2 has determined that the web 1 cannot be browsed and that the host 1 has determined that the web 1 can be browsed. FIG. 45 shows a procedure for narrowing down the cause of a failure using such information. FIG. 46 shows the narrowing rules used at that time.

(Step 1) The input / output module 26 transmits information that “web1 cannot be browsed from host2” to the cause inference module.
(Step 2) The failure cause inference module 14 obtains from the host 2 a cause candidate that the web1 cannot be browsed by the procedure shown in FIG.
(Step 3) As a result, the fault cause inference module 14 obtains the fault tree of FIG. 44- (b).
(Step 4) The failure cause inference module 14 sends the host2 fault tree to the input / output module 26.
(Step 5) Next, the input / output module 26 transmits information that "web1 cannot be browsed from host1" to the cause inference module.
(Step 6) The failure cause inference module 14 obtains a cause candidate from which the web1 cannot be browsed from the host1 by the procedure shown in FIG.
(Step 7) As a result, the fault cause inference module 14 obtains the fault tree of FIG.
(Step 8) The fault cause inference module 14 sends the host1 fault tree to the input / output module 26.
(Step 9) The input / output module 26 sends a cause narrowing request to the cause narrowing module together with the host 2 fault tree (failure state) and the host 1 fault tree (normal state).
(Step 10) The cause inference module narrows down the cause by the fault tree in the fault state and the fault tree in the normal state as follows. Comparing FIG. 44- (a) and (b), underlined rows appear in both. Actually, since web1 can be browsed from host 1, the instance appearing in the fault tree of host 1 is operating normally. Therefore, the underlined line can be deleted from the host 2 fault tree. As a result, the result of FIG. 44- (c) can be obtained. The lines shown in bold type indicate failure cause candidates at the physical level. The cause narrowing down module sends the result to the failure cause inference module 14.
(Step 11) The fault cause inference module 14 transmits the narrowed-down host2 fault tree to the input / output module 26.

[Operation example of network configuration information collection module]
Examples of the network configuration information collection module 11 include a KANVAS system having a KANVAS architecture described in Non-Patent Document 4, for example. FIG. 47 shows a configuration example of the KANVAS system. The KANVAS system includes a KANVAS Information Collector (KIC) 30 functioning as an information collecting device, a KANVAS Storage Server (KSS) 20 functioning as a storage server device, a KANVAS Access Server (KAS) 10 and an Invasor KANSAS serving as an access server device. It has four main modules, (KIG) 50.

The KAS 10 is an application that can be used by end nodes such as the administrator 42 and the user 43.
One KSS 20 logically exists in an AS (Autonomous System: network range operated by a unified management policy) network 44. Although it may physically exist in a plurality of nodes for load distribution, it is assumed that there is only one logically. Depending on the size of the AS network 44, the KAS 10 and the KIC 30 may be provided one in the AS network 44, or may be provided in plurals for load distribution.

  The KIC 30 collects various network information such as route information and device information from the AS network 44. For example, the route information is collected by participating in a protocol such as OSPF (Open Shortest Path First) defined by RFC2328 and BGP-4 (Border Gateway Protocol 4) defined by RFC4271. In addition, device information and statistical information are collected by accessing each device using SNMP (Simple Network Management Protocol) defined by RFC3416 or NETCONF defined by RFC6241. Network flow information is collected using sFlow defined by RFC3176 and NetFlow defined by RFC3954. The failure information is collected using CLINEX (Patent Document 1) or the like. The obtained information is expressed as an instance of the network ontology Bonsai and stored in the knowledge base (network configuration information RDF storage 21).

  The KIG 50 operates on a device connected to the AS network 44, automatically collects a network configuration in a specified target range (for example, a corporate network), detects the network configuration, and stores a database (network configuration information RDF storage) of the KSS 20. 21).

  FIG. 48 shows the internal structure of the KIG. The KIG 50 includes an API module 51, a KSS interface module 52 functioning as a storage information obtaining unit, a controller module 53, a MIB (Management information base) obtaining module 54 and a service determining module 55 functioning as an additional information obtaining unit, An instance generation module 56 that functions as a configuration detection unit. The KIG 50 may realize each functional unit provided in the KIG 50 by causing a computer to execute a program.

  The API module 51 provides an interface for the user 43 and the application 41 to access the KIG 50. The KSS interface module 52 performs a process in which the KIG 50 obtains information stored in the database of the KSS 20 and stores information of the network configuration detected by the KIG 50 in the database of the KSS 20. As a result, the KSS interface module 52 can acquire from the database in which the ASA3 network information is stored.

  The KSS interface module 52 acquires information from an arbitrary database of the KSS 20. For example, in FIG. 47, two examples of the KSS 20 database are an RDF database (network configuration information RDF storage 21) for storing data described in RDF (Resource Description Framework) and a time-series database for storing time-series data. The following shows an example in which a database is provided. In this case, the KSS interface module 52 may acquire information from any one of the RDF database and the time-series database.

  The controller module 53 controls the operation of the KIG 50. The MIB (Management Information Base) acquisition module 54 accesses the network device by SNMP, and acquires various MIBs (Management Information Bases) defined by RFC1213 and RFC3418. The service determination module 55 accesses the network device and determines whether the service is operating. The instance generation module 56 expresses the network configuration of the target range as an instance of Bonsai based on the information obtained by the MIB acquisition module 54 and the service determination module 55 and stores it in the KSS 20.

  The operation of the KIG will be described below using an example. FIG. 49 shows an example of an AS network from the viewpoint of an IP subnet. This AS network is composed of five routers (router # 1 to router # 5) and six IP subnets (subnet # 1 to subnet # 6).

  A server machine, an HTTP server (Web server), an SMTP server (mail server), a DNS server, a KSS 20, and a KIG 50 are connected to the subnet # 1. In addition, a DHCP server is operating in the router # 5. It is assumed that OSPF operates as a routing protocol between the routers. It is assumed that the KIC 30 collects the LSDB (Link State Database) of the OSPF and stores it in the KSS 20.

  FIG. 50 shows the physical configuration of the AS network. All subnets are configured via switches (switches SW # 1 to SW # 5). Among them, the subnets # 4 and # 5 are configured by VLANs (Virtual LAN) sharing the switch SW # 4.

  A server machine, an HTTP server, an SMTP server, a DNS server, a KSS 20 and a KIG 50 are connected to the subnet # 1, and the HTTP server and the SMTP server are virtual machines and operate on the server machine. A Wi-Fi access point # 1 is installed on the subnet # 6, and a host # 7 is connected via Wi-Fi. It is assumed that an LLDP (Link Layer Discovery Protocol) specified by IEEE 802.1AB is operating in each switch or access point # 1.

  It is assumed that the user or the application has activated the instance generation module 56 of the network configuration via the API module 51 of the KIG 50. The target range for detecting the network configuration is specified by a network prefix or the like. In this example, it is assumed that a network prefix including subnets # 1 to # 6 has been designated.

  FIG. 51 shows a flowchart of the network configuration detection method according to the present embodiment. In the network configuration detection method according to the present embodiment, the KIG 50 sequentially executes a stored information acquisition procedure (S101), an additional information acquisition procedure (S102 to S107), and a network configuration detection procedure (S108 to S109).

Step S101. Acquisition of IP network configuration information (1): Acquisition of IP network configuration information by a router existing in the target range.
In the example of FIG. 50, the controller module 53 of the KIG 50 accesses the KSS 20 via the KSS interface module 52, and acquires information on the network configuration of the target range from the database. When the LSDB of the target range is stored in the database of the KSS 20, the controller module 53 obtains the LSDB in which the IP addresses of the routers # 1 to # 5 are described. Thereby, the KIG 50 can know the IP nodes (reference numeral C3 shown in FIG. 2) of the routers # 1 to # 5.

Step S102. Acquisition of IP network configuration information (2): Acquisition of interface information and inter-router relation information of routers existing in the target range.
In the example of FIG. 50, the controller module 53 of the KIG 50 inquires the routers # 1 to # 5 by SNMP via the MIB acquisition module 54, and obtains interface information (interface type, IP address, netmask, etc.) of each router. Get) For example, objects such as IfType, ipAdEntAddr, and ipAdEntNetMask defined in the MIB are referred to. As a result, the KIG 50 can obtain the IP subnet C1, the IP interface C2, and the IP network configuration C4 of the routers # 1 to # 5.

That is, the following information as shown in FIG. 52 is obtained.
Router # 1, Router # 2, and Router # 3 are connected to subnet # 1.
The router # 2, the router # 4, and the router # 5 are connected to the subnet # 2.
-Router # 3 is connected to subnet # 3.
-Router # 4 is connected to subnet # 4.
-Router # 4 is connected to subnet # 5.
-Router # 5 is connected to subnet # 6.

Step S103. Acquisition of IP network configuration information (3): Acquisition of Layer-3 device information other than routers existing in the target range.
In the example of FIG. 50, the controller module 53 of the KIG 50 inquires the routers # 1 to # 5 by SNMP via the MIB acquisition module 54 to obtain a correspondence table between the IP addresses and the MAC addresses of the devices connected to each subnet. For example, an object such as ipNetToMediaTable defined in MIB is referred to. Thereby, the KIG 50 can obtain the IP node C3, the logical node D3, and the physical node E3 of each device.

That is, the following information as shown in FIG. 53 is obtained.
-Five devices other than the routers # 1, # 2, # 3, KIG50 and KSS20 are connected to the subnet # 1.
-Two devices other than the routers # 2, # 4, and # 5 are connected to the subnet # 2.
-Two devices other than the router # 3 are connected to the subnet # 3.
-Two devices other than the router # 4 are connected to the subnet # 4.
-Two devices other than the router # 4 are connected to the subnet # 5.
-Four devices other than the router # 5 are connected to the subnet # 6.

Step S104. Acquisition of physical / logical network configuration information (1): Acquisition of information on Layer-2 device existing in the target range.
In the example of FIG. 50, the controller module 53 of the KIG 50 inquires each router by SNMP via the MIB acquisition module 54 to obtain LLDP information. For example, an object such as lldpRemTable defined in LLDP-MIB is referred to. Also, for a Layer-2 device having an IP address, such as a switch, the value is also obtained. Thereby, the KIG 50 can obtain the physical node E3 functioning as a connection device.

That is, the following information as shown in FIG. 54 is obtained.
Switch SW # 1 is connected to subnet # 1.
Switch SW # 2 is connected to subnet # 2.
Switch SW # 3 is connected to subnet # 3.
Switch SW # 4-1 is connected to subnet # 4.
Switch SW # 4-2 is connected to subnet # 5.
Switch SW # 5 and access point # 1 are connected to subnet # 6.

Step S105. Acquisition of physical / logical network configuration information (2): Acquisition of relationship information between Layer-3 devices and Layer-2 devices existing in the target range.
The controller module 53 obtains information on the downstream network controlled by each network device from the network devices that control the routes in the target range, and specifies the logical network configuration in the target range using the information. In the example of FIG. 50, the controller module 53 of the KIG 50 inquires the switches SW # 1 to SW # 5 and the access point # 1 by SNMP via the MIB acquisition module 54 by SNMP, and checks the devices connected to each switch and the access point # 1. Get the MAC address. For example, an object such as dot1dTpPortTable defined in MIB is referred to. By matching the result with the MAC address obtained in step S103, the KIG 50 obtains the logical node D3, the logical interface D2, the logical link D1, the logical network configuration D4, the physical interface E2, the physical link E1, and the physical network configuration E4. be able to.

That is, the following information as shown in FIG. 55 is obtained.
Router # 1, Router # 2, Router # 3, KSS20, KIG50, Host # 1-1, Host # 1-2, Host # 1-3, Host # 1-4 are connected to switch SW # 1. I have.
Router # 2, Router # 4, Router # 5, and Host # 2 are connected to switch SW # 2.
Switch SW # 4-1 and switch SW # 4-2 are physically one switch (switch SW # 4).
The subnet # 4 and the subnet # 5 are VLANs, and share the switch SW # 4.
Router # 4, host # 4, and host # 5 are connected to switch SW # 4.
The host # 6 and the access point # 1 are connected to the switch SW # 5.
-Host # 7 is connected to access point # 1.

Step S106. Identification of logical network configuration information and physical network configuration information.
In the example of FIG. 50, the controller module 53 of the KIG 50 inquires each host via the MIB acquisition module 54 by SNMP, and determines whether a hypervisor for realizing a virtual machine environment is operating and, if so, what virtual Get if the machine is running. For example, an object such as vmMIB defined in MIB defined in RFC7666 is used. As a result, the KIG 50 knows that the host # 1-2 and the host # 1-3 are operating as virtual machines (VM) on the host # 1-1. That is, information as shown in FIG. 56 is obtained.

Step S107. Get network service configuration information.
In the example of FIG. 50, the controller module 53 of the KIG 50 accesses each terminal, that is, each host included in the target range via the service determination module 55, and configures the network service configuration B3 included in the target range. Identify. The access is, for example, an access to a port corresponding to the network server in the routers # 1 to # 5 and the hosts # 1-1 to # 7. The access port is a port corresponding to the service. For example, the HTTP server is port 80, the SMTP server is port 25, the DNS server is port 53, and the DHCP server is port 67. Specifically, when TCP (Transmission Control Protocol) is used like an HTTP server or an SMTP server, an attempt is made to establish a TCP connection by specifying a corresponding port number.

  When the TCP connection is established, it is determined that the corresponding server is operating. If an ICMP (Internet Control Message Protocol) port unreachable is returned or the TCP connection establishment fails, it is determined that the corresponding server is not operating.

  When using UDP (User Datagram Protocol) like a DNS server or a DHCP server, a UDP segment is transmitted to a corresponding port number. If a segment indicating an ICMP port unreachable or an error is returned, it is determined that the corresponding server is not operating. In other cases, it is determined that the corresponding server is operating.

  As a result, it is assumed that the HTTP server operates on the host # 1-2, the SMTP server operates on the host # 1-3, the DNS server operates on the host # 1-4, and the DHCP server operates on the router # 5. know. Thereby, the KIG 50 can obtain the service entity B2, the network service B1, and the network service configuration B3 in the network service B. That is, physical configuration information as shown in FIG. 56 is obtained.

  In steps S102 to S107, the devices included in the target range are specified using the information obtained by the KSS interface module 52, and the information that the KSS interface module 52 of the network configuration of the target range could not be obtained from the specified device. Can be obtained.

Step S108.
The controller module 53 of the KIG 50 passes the obtained network configuration information to the instance generation module 56. The instance generation module 56 expresses the network configuration of the target range in a predetermined format and generates an instance.

Step S109.
The controller module 53 of the KIG 50 transmits the instance representation obtained via the KSS interface module 52 to the KSS 20.

[Effects of the Invention]
-By using the network ontology Bonsai as a data model, both fault influence range inference and fault cause inference can be performed.
In fault inference range inference, since dependency rules are developed when the network configuration is determined, there is no need to deploy the dependency rules at runtime. Therefore, the memory consumption at the time of execution is suppressed, and the execution can be performed at high speed.
-In fault cause inference, all search is avoided by not deploying analysis rules for instances that are not dependent and state propagation that is not related to symptoms, and can be applied to large-scale systems.
・ It is possible to narrow down the cause using multiple observation information in fault cause inference.

[Purpose of Invention]
-In inference of the range of influence of a failure, a dependency rule must be developed and stored in advance in the network configuration information.
-In fault cause inference, do not deploy analysis rules for instances that are not dependent or state propagation that is not related to symptoms.
-In fault inference, it is possible to narrow down the cause using multiple pieces of observation information.

10: KANVAS Access Server (KAS)
11: Network configuration information collection module 12: SPIN inference engine 13: Influence range inference module 14: Failure cause inference module 15: Failure cause narrowing down module 20: KANVAS Storage Server (KSS)
21: Network Configuration Information RDF Storage 22: SPIN Dependency Rule Storage 23: Dependency Rule Expansion Storage 24: SPIN State Propagation Rule Storage 25: Rule Input Module 26: Input / Output Module 27: Temporary Dependency Rule Expansion Storage 30: KANVAS Information Collector (KIC)
44: Network 50: KANVAS Instance Generator (KIG)
51: API module 52: KSS interface module 53: Controller module 54: MIB acquisition module 55: Service determination module 56: Instance generation module

Claims (8)

A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. Setting means for setting a propagation rule;
Storage means for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When failure information on the element is input, select the element that has an effect on the state from the stored dependency rules, detect the state propagation rule based on the selected element, Range estimating means for estimating the range of the element affected by the failure information;
A fault influence range inference device comprising:   2. The fault influence range inference apparatus according to claim 1, further comprising: a fault information response unit configured to make a response to the input fault information an influence on a service of a network from the estimated range of the element. A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. Setting means for setting a propagation rule;
Storage means for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When a fault condition for the network is input, one or more of the elements related to the fault condition are selected from the stored dependency rules, and one or more of the selected elements can be taken. The state estimation rule is searched based on the selected element and the searched state to detect the state propagation rule, and the cause estimation for estimating the list of the element causing the failure state and the state of the element is performed. Means for estimating the cause
An inference device for causing a failure cause, comprising:   Causing the cause estimating means to perform the cause estimation assuming another failure situation similar to the failure situation, and estimating another list of the element and the state of the element that cause the other failure situation; 4. The fault cause according to claim 3, further comprising: a fault status response unit that sets a result of excluding items common to the list and the other list from the list as a response to the input fault status. Inference device. A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. A setting procedure for setting a propagation rule,
A storage procedure for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When failure information on the element is input, select the element that has an effect on the state from the stored dependency rules, detect the state propagation rule based on the selected element, A range estimation procedure for estimating the range of the element affected by the failure information,
The method for inferring the range of the influence of a failure characterized by performing the following. A dependency rule describing a dependency relationship between two elements of which a state is dependent on each other among a plurality of elements constituting a network, and a state describing contents of a state propagated between the two elements. A setting procedure for setting a propagation rule,
A storage procedure for collecting information about the configuration of the network, extracting and storing the dependency rules according to the configuration of the network,
When a fault condition for the network is input, one or more of the elements related to the fault condition are selected from the stored dependency rules, and one or more of the selected elements can be taken. A state estimating step of detecting the state propagation rule based on the selected element and the searched state, and estimating a list of the element causing the failure state and the state of the element When,
Inference method of the cause of failure characterized by performing.   A program for causing a computer to function as the fault influence range inference device according to claim 1.   A program for causing a computer to function as the failure cause inference device according to claim 3.

Images