WO2012131868A1 - 計算機システムの管理方法及び管理装置 - Google Patents

計算機システムの管理方法及び管理装置 Download PDF

Info

Publication number
WO2012131868A1
WO2012131868A1 PCT/JP2011/057592 JP2011057592W WO2012131868A1 WO 2012131868 A1 WO2012131868 A1 WO 2012131868A1 JP 2011057592 W JP2011057592 W JP 2011057592W WO 2012131868 A1 WO2012131868 A1 WO 2012131868A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
management
predetermined
information
computer system
Prior art date
Application number
PCT/JP2011/057592
Other languages
English (en)
French (fr)
Inventor
崇之 永井
正剛 名倉
沢希 黒田
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to JP2013506894A priority Critical patent/JP5352027B2/ja
Priority to PCT/JP2011/057592 priority patent/WO2012131868A1/ja
Priority to US13/143,493 priority patent/US8583789B2/en
Publication of WO2012131868A1 publication Critical patent/WO2012131868A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0727—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a storage system, e.g. in a DASD or network based storage system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3034—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a storage system, e.g. DASD based or network based
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G06F11/3079—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved by reporting only the changes of the monitored data

Definitions

  • the present invention relates to a computer system management method and management apparatus.
  • Patent Document 1 When management software that manages a computer system having a large number of node devices detects a failure or a sign of a failure, the management software estimates a cause event from the failure (Patent Document 1). More specifically, the management software described in Patent Document 1 converts various faults that occur in each managed device into events, and accumulates event information in an event database.
  • the management software has an analysis engine. The analysis engine analyzes a causal relationship between a plurality of failure events that have occurred in the managed device.
  • the analysis engine accesses a configuration database having inventory information of managed devices and recognizes in-device components on the I / O (Input / Output) system as a group called “topology”.
  • the analysis engine builds a causality matrix by applying a fault propagation model to the topology.
  • the fault propagation model is composed of conditional statements and analysis results that are determined in advance.
  • the causality matrix includes a cause event indicating a cause failure and a related event group indicating a failure caused by the cause event.
  • the event described as the root cause of the failure in the THEN part of the rule is the cause event.
  • Events other than the cause event among the events described in the IF part of the rule are related events.
  • the failure When a failure occurs in a certain device in the computer system, the failure is the cause, and another failure also occurs in one or more other devices connected to the failed device. As a result, a plurality of faults are found in the computer system.
  • Management software that manages various node devices such as host computers, network devices, and storage devices has a failure analysis function.
  • the management software uses an analysis function to present a failure that is a root cause among a plurality of failures to the administrator.
  • the fault analysis engine for realizing the fault analysis function has a plurality of event propagation models defined based on fault analysis know-how.
  • the management software acquires the topology between the devices from the configuration information of the node device, and applies the event propagation model to the topology.
  • the management software outputs a causality matrix that indicates the correspondence between the failure event that has occurred in the device and the event that is the root cause of the failure.
  • the failure analysis engine stores a causal matrix in a storage area and uses it for failure analysis.
  • the management software discards the causality matrix every time it detects a change in the stored configuration information.
  • the management software develops the event propagation model based on the latest topology, and newly creates a causality matrix corresponding to the latest configuration. Thereafter, every time the configuration of the computer system changes, an event propagation model expansion process is executed.
  • the configuration changes detected by the management software include configuration changes that do not require redeployment of the event propagation model.
  • the event propagation model is redeployed, so the processing load of the management software increases. For example, in a computer system such as a large-scale data center, the number of node devices is large, so that the configuration changes relatively frequently for repair or inspection, expansion or reduction.
  • the present invention has been made in view of the above problems, and it is an object of the present invention to provide a management method and a management apparatus for a computer system that can reduce the processing load for management.
  • the computer system includes a plurality of node devices and a management device for managing the plurality of node devices.
  • the management device holds at least one predetermined analysis rule and target event management information for managing a correspondence relationship between an event that can be detected by the management device and the predetermined analysis rule.
  • the predetermined analysis rule defines a relationship between a cause event causing a failure and a related event indicating a failure caused by the cause event.
  • the management device acquires configuration information from a plurality of node devices, and the predetermined process identifies an analysis rule to be processed based on the detected event and target event management information, and the identified analysis rule is used as the configuration information.
  • the processing may be applied to generate information for failure analysis. For example, specific information (for example, a causal matrix described later) for analyzing a failure may be generated by applying a predetermined analysis rule to a specific configuration of the computer system.
  • the management device may create and hold target event management information based on the contents of a predetermined analysis rule.
  • the management device holds topology generation information for storing a plurality of topology generation methods for generating a topology indicating a connection relationship between the node devices, and generates a topology generation method corresponding to a predetermined analysis rule.
  • the target event management information may be created and held by registering the node device obtained from the information and registered in the target event management information as the event generation source. .
  • the management device is configured to create and hold the target event management information at a predetermined timing.
  • the predetermined timing means that the management device is started for the first time or a new predetermined analysis rule is added. Or at least one of cases where an existing predetermined analysis rule is deleted or changed.
  • the cause of the detected failure may be estimated based on information for failure analysis.
  • the present invention can also be understood as a computer system management method and a computer program for managing the computer system.
  • FIG. 1 It is a figure which shows the physical structural example of a computer system. It is a figure which shows the structural example of a host computer. It is a figure which shows the structural example of a storage apparatus. It is a figure which shows the structural example of a management server. It is a figure which shows the structural example of an IP switch. It is a figure which shows the structural example of a logical volume management table. It is a figure which shows the other example of a logical volume management table. It is a figure which shows the further another example of a logical volume management table. It is a figure which shows the structural example of a volume management table. It is a figure which shows the other example of a volume management table.
  • a deployment target event management table is used to determine whether or not to deploy.
  • the development target event management table defines, for example, the types of events that require redeployment processing among the configuration change events and the event propagation model to be redeployed in association with each other.
  • the event propagation model redeployment process can be executed only for the configuration change event that requires the event propagation model redeployment process. Therefore, the processing load for managing the system can be reduced.
  • the contents of the deployment target event management table are automatically updated.
  • the information used in the embodiment is described by the expression “aaa table”.
  • the present invention is not limited to this.
  • “aaa list”, “aaa database”, “aaa queue” Other expressions such as may be used.
  • aaa information In order to show that the information used in the present embodiment does not depend on the data structure, it may be referred to as “aaa information”.
  • identification information In describing the contents of information used in the present embodiment, the expressions “identification information”, “identifier”, “name”, “name”, and “ID” may be used, but these may be replaced with each other. Is possible.
  • “computer program” or “module” may be described as an operation subject (subject).
  • the program or module is executed by a microprocessor.
  • the program or module executes a predetermined process using a memory and a communication port (communication control device). Therefore, the processor may be read as the operation subject (subject).
  • Processing disclosed with a program or module as the subject may be read as processing performed by a computer such as a management server. Furthermore, part or all of the computer program may be realized by dedicated hardware.
  • the computer program may be installed in the computer by a program distribution server or a storage medium.
  • 1 to 5 show the overall configuration of the computer system and the configuration of each device connected to the computer system.
  • 6 to 14 show management information included in each device.
  • FIG. 1 is a diagram showing a physical configuration of a computer system.
  • the computer system includes, for example, a host computer 10, a storage device 20, a management server 30, an IP switch 40, and a web server 50.
  • Each device 10, 20, 30, 40, 50 is connected to be communicable by a communication network 60.
  • the host computers 10 (1) and 10 (2) receive a file I / O request from a client computer (not shown), and send them to the storage devices 20 (1) and 20 (2) based on the I / O request. to access.
  • the management server (management computer) 30 manages the operation of the entire computer system. If it is not necessary to distinguish between them, the host computers 10 (1) and 10 (2) are called the host computer 10 and the storage devices 20 (1) and 20 (2) are called the storage device 20.
  • the web server 50 is connected to the GUI (Graphical) of the management server 30 via the communication network 60.
  • User Interface communicates with the display processing module P33 to display various information on the web browser.
  • the user manages each device 10, 20, 40 in the computer system by referring to the information displayed on the WEB browser of the web server 50.
  • a portable computer such as a mobile phone or a portable information terminal may be used to refer to information provided by the management server 30 or to give an instruction to the management server 30.
  • the management server 30 and the web server 50 may be configured to be provided in one server.
  • the host computer 10 may be provided with at least one of the functions of the management server 30 and the web server 50.
  • FIG. 2 shows an example of the internal configuration of the host computer 10.
  • the host computer 10 includes, for example, a communication port 100, a processor (CPU in the figure) 110, and a memory 120. These 100, 110, and 120 are connected via an internal bus or the like.
  • the communication port 100 is a circuit for communicating via the communication network 60.
  • the processor 110 reads and executes various computer programs stored in the memory 120.
  • the memory 120 for example, an application program P11, an operating system P10, and a logical volume management table T10 are stored.
  • the memory 120 may include a storage device such as a flash memory device or a hard disk drive, for example.
  • the application program P11 uses the storage area provided from the operating system P10 and inputs / outputs data to / from the storage area.
  • the application program (sometimes abbreviated as application) P10 is configured, for example, as a customer management program, a sales management program, a moving image distribution program, and the like, and provides a service to a client computer (not shown).
  • the operating system P10 causes the application program P11 to recognize the logical volume 232 (see FIG. 3) of the storage apparatus 20 connected to the host computer 10 as a storage area.
  • the port 100 includes both the I / O port and the management port.
  • the I / O port and the management port may be provided separately.
  • the I / O port is a communication port for communicating with the storage apparatus 20 by iSCSI.
  • the management port is a communication port for the management server 30 to acquire management information in the host computer 10.
  • FIG. 3 shows an internal configuration example of the storage apparatus 20.
  • the storage device 20 includes, for example, I / O ports 200 (1) and 200 (2), a management port 201, controllers 210 (1) and 210 (2), a management memory 220, and a storage device 230. . These 200, 201, 210, 220, and 230 are connected by an internal bus or the like.
  • the I / O ports 200 (1) and 200 (2) are communication ports for connecting to the host computer 10 via the communication network 60. If they are not distinguished, they are called I / O ports 200.
  • the management port 201 is a communication port for connecting to the management server 30 via the communication network 60.
  • Controllers 210 (1) and 210 (2) are devices for controlling the operation of the storage apparatus 20. When not distinguished, the controllers 210 (1) and 210 (2) are referred to as a controller 210.
  • Each controller 210 includes therein a processor for controlling the operation of the storage apparatus 20 and a cache memory for temporarily storing data transmitted to and received from the host computer 10. Each controller 210 is interposed between the I / O port 200 and the RAID group 231 and exchanges data between them.
  • the controller 210 has a redundant configuration, and even when one of the controllers stops, the other controller can take over control of the storage apparatus 20.
  • the RAID group 231 includes one or more storage devices 230.
  • a RAID group 231 can also be generated by using a physical storage area of each of the plurality of storage devices 230 as a RAID configuration.
  • One or more logical volumes 232 which are logical storage areas, can be provided in the RAID group 231.
  • the logical volume 232 can also be generated based on the physical storage area of one storage device 230. In this case, the physical storage area need not have a RAID configuration.
  • the storage device 230 for example, various storage devices that can read and write data such as a hard disk device, a semiconductor memory device, an optical disk device, and a magneto-optical disk device can be used.
  • FC Fibre Channel
  • SCSI Serial Computer System Interface
  • SATA Serial Advanced Technology Attachment
  • SAS Serial Attached SCSI
  • various storage devices such as flash memory, FeRAM (Ferroelectric Random Access Memory), MRAM (Magnetoresistive Random Access Memory), phase change memory (Ovonic Unified Memory), RRAM (Resistance RAM) can be used. Further, for example, a configuration in which different types of storage devices such as a flash memory device and a hard disk device are mixed may be used.
  • a management program P20 for managing storage devices for example, a volume management table T20, an iSCSI target management table T21, an I / O port management table T22, and a RAID group management table T23 are stored.
  • the Details of the management tables T20, T21, T22, and T23 will be described later.
  • the management program P20 communicates with the management server 30 via the management port 201, and provides the configuration information of the storage device 20 to the management server 30.
  • the storage device 20 is not limited to the configuration shown in FIG.
  • the storage device 20 only needs to include a storage controller and a storage device.
  • the storage controller has a function of providing a logical volume to the host computer 10, a function of reading and writing data based on an access request (I / O request) from the host computer 10, and a function of temporarily storing data. It only has to have.
  • the storage controller and the storage device do not need to be provided in the same casing, and may be provided in separate casings.
  • the storage device 20 may be referred to as a storage system.
  • FIG. 4 shows an example of the internal configuration of the management server 30.
  • the management server 30 includes, for example, a management port 300, a processor 310, a memory 320, a secondary storage area 330, an output device 340, and an input device 350.
  • These 300-350 are circuits such as an internal bus. Are connected to each other.
  • the management port 300 is a circuit that communicates with the management server 30 via the communication network 60.
  • the processor 310 reads and executes software modules P30 to P35 described later.
  • the output device 340 includes, for example, a display, a printer, a speaker, and the like.
  • the output device 340 outputs a processing result described later.
  • the input device 350 includes, for example, a keyboard, a mouse, a touch panel, a microphone, and the like.
  • the administrator storage administrator gives an instruction to the management server 30 via the input device 350.
  • the memory 320 stores, for example, a program control module P30, a configuration information acquisition module P31, a state acquisition module P32, a GUI display processing module P33, an event analysis processing module P34, and an event propagation model expansion module P35. Has been. Details of each module will be described later. In the drawing, for the sake of convenience, some module names may be omitted. For example, the event analysis processing module P34 is displayed as an event analysis module in the drawing.
  • each module is provided as a software module stored in the memory 320, but each module may be generated as a hardware module instead. Further, the processing performed by each module may be provided as one or more program codes. Furthermore, there may not be a clear boundary between modules.
  • the secondary storage area 330 includes, for example, an event management table T30, an event propagation model repository T31, a causality matrix T32, a topology generation method repository T33, a deployment target event management table T34, and a deployment target event propagation model management table.
  • T35 and the configuration database T36 are stored.
  • a symbol T31 may be attached to the event propagation model
  • a symbol T33 may be attached to the topology generation method.
  • Each configuration information collected by the configuration information acquisition module P31 is stored in the configuration database T36.
  • the configuration information includes information acquired from the host computer 10 and information acquired from the storage device 20.
  • Information acquired from the host computer 10 includes a logical volume management table T10.
  • Information acquired from the storage device 20 includes a volume management table T20, an iSCSI target management table T21, an I / O port management table T22, and a RAID group management table T23.
  • the secondary storage area 330 can be composed of, for example, one or both of a flash memory device and a hard disk drive. Instead of the secondary storage area 330, the management tables T30 to T36 may be stored in the memory 320. A part of the management tables T30 to T36 stored in the secondary storage area 330 may be stored in the memory 320.
  • the status acquisition module P32 periodically accesses each node device (host computer 10, storage device 20) to be managed, and acquires the status of each component in each node device.
  • the event analysis processing module P34 refers to the causality matrix T32 and analyzes the root cause of the abnormal state of the node device acquired by the state acquisition module P32.
  • the GUI display processing module T33 displays the configuration information acquired from each node device via the output device 340 in response to a request from the administrator via the input device 350.
  • the input device 350 and the output device 340 may be separate devices, or may be configured as one or more integrated devices.
  • the management server 30 may be composed of one computer or a plurality of computers. Furthermore, a display computer may be connected to the management server 30 instead of the output device 340 and the input device 350.
  • the display computer includes an input device and an output device. The administrator can acquire information from the management server 30 or give an instruction to the management server 30 via the display computer.
  • the display computer and the management server 30 are connected, for example, wirelessly or by wire.
  • the display computer can be configured as a personal computer, a mobile phone, or a portable information terminal.
  • a set of one or more computers that manage a computer system (information processing system) and display display information may be referred to as a management system.
  • the management server displays the display information
  • the management server is a management system.
  • a combination of a management server and a display computer (for example, the web server 50) is also a management system.
  • a process equivalent to the management server may be realized by a plurality of computers in order to increase the speed or reliability of the management process.
  • the plurality of computers (including the display computer when the display computer performs display) is the management system.
  • FIG. 5 shows the configuration of the IP switch 40.
  • the IP switch 40 includes, for example, a processor 410, a memory 420, I / O ports 400 (1) and 400 (2), and a management port 401. These 410, 420, 400, and 401 are internal buses or the like. Are connected to each other.
  • the memory 420 stores, for example, a control program and various management information (both not shown).
  • the processor 410 executes a control program and controls the operation of the IP switch 40.
  • the I / O ports 400 (1) and 400 (2) are connected to the host computer 10 via the communication network 60.
  • the management port 401 is connected to the management server 30 via the communication network 60.
  • the logical volume management table T10 is information for managing logical volumes used by the host computer 10.
  • the logical volume management table T10 includes, for example, a drive name C100, an iSCSI initiator name C101, a connection destination iSCSI target C102, and a LUN. Each field of ID C103 is managed in association with each other.
  • the drive name C100 is a field for registering a drive name that becomes an identifier of each logical volume 232 in the host computer 10.
  • the iSCSI initiator name C101 is a field for registering the iSCSI initiator name.
  • the iSCSI initiator is an identifier of the I / O port 100 of the host computer 10 that is used for communication with the storage apparatus 20 in which the entity of the logical volume 232 exists.
  • the connection destination iSCSI target C102 is an identifier of the I / O port 200 of the storage apparatus 20 used for communication with the storage apparatus 20 in which the entity of the logical volume 232 exists.
  • the LUN ID C103 is a LUN (Logical Unit) that is an identifier of the logical volume 232 in the storage device. Number) A field for registering an ID.
  • FIG. 6A shows an example of specific values of the logical volume management table T10.
  • the first line of FIG. 6A describes a logical volume indicated by a drive name (E :) on the host computer.
  • the logical volume (E :) consists of a port 100 on the host computer indicated by the iSCSI initiator name “com.abc.sv1” and a port on the storage device indicated by the iSCSI target name “com.abc.sto1”.
  • the storage apparatus 20 is connected to the storage apparatus 20.
  • the logical volume (E :) is given a LUN ID “0” on the storage device.
  • FIG. 7A and 7B are diagrams showing the volume management table T20.
  • the volume management table T20 manages each logical volume 232 in the storage apparatus 20.
  • the volume management table T20 manages, for example, the fields of volume ID C200, capacity C201, RAID group ID C202, target ID C203, and LUN ID C204 in association with each other.
  • Volume ID C200 is an identifier of each logical volume 232 of the storage apparatus 20.
  • the saddle capacity C201 is the capacity of each volume 232.
  • the RAID group ID C202 is an identifier of the RAID group 231 to which each volume 232 belongs.
  • the target ID C203 is an identifier of the iSCSI target to which each volume 232 belongs.
  • the LUN ID C204 is an identifier in the iSCSI target of each volume 232.
  • FIG. 7A shows an example of specific values of the volume management table T20.
  • the volume 232 (VOL1) has a storage area of 20 GB and belongs to the RAID group 231 (RG1). Further, the volume 232 (VOL1) belongs to the iSCSI target specified by the iSCSI target ID (TG1) and has a LUN ID (0).
  • the iSCSI target management table T21 manages iSCSI targets in the storage apparatus 20.
  • the iSCSI target management table T21 manages, for example, the fields of the target ID C210, the iSCSI target name C211 and the connection permission iSCSI initiator C212 in association with each other.
  • Target ID C210 is an iSCSI target identifier.
  • the iSCSI target name C211 is an iSCSI target name that each iSCSI target has.
  • the connection permitted iSCSI initiator C212 is the name of the iSCSI initiator permitted to connect to the iSCSI target. That is, in the field C212, an iSCSI initiator name that is an identifier of the port 100 of the host computer 10 that is permitted to access the logical volume 232 belonging to the iSCSI target is registered.
  • FIG. 8A shows an example of specific values of the iSCSI target management table T21. Focusing on the first line, the iSCSI target (HG1) of the storage apparatus 20 has the iSCSI target name “com.abc.sto1”. Further, the iSCSI target (HG1) permits access from the port 100 of the host computer 10 whose iSCSI initiator name is “com.abc.sv1” or “com.abc.sv11”.
  • FIG. 9 shows the configuration of the I / O port management table T22.
  • the I / O port management table T22 manages the I / O port 200 of the storage apparatus 20.
  • the I / O port management table T22 manages, for example, the fields of the port ID C220 and the target ID C221 in association with each other.
  • the port ID C220 is an identifier of each port 200 of the storage device 20.
  • the target ID C221 is a MAC address that serves as an identifier on the communication network 60 of the port 200.
  • FIG. 9 shows an example of specific values of the I / O port management table. Focusing on the first line, the port 200 (PORT1) of the storage apparatus 20 is used by the iSCSI target specified by the iSCSI target IDs TG1 and TG2.
  • FIG. 10 shows the configuration of the RAID group management table T23.
  • the RAID group management table T23 manages each RAID group 231 in the storage apparatus 20.
  • the RAID group management table T23 manages, for example, the fields of the RAID group ID C230, the RAID level C231, and the capacity C232 in association with each other.
  • RAID group ID C230 is an identifier in the storage device of each RAID group 231.
  • the RAID level C231 is the RAID level of the RAID group 231.
  • As the RAID level for example, RAID1, RAID2, RAID3, RAID4, RAID5, and RAID6 are known.
  • the capacity C232 is the capacity of the RAID group 231.
  • FIG. 10 shows an example of specific values of the RAID group management table T23. Focusing on the first row, the RAID group 231 (RG1) has a RAID level of RAID1 and a capacity of 100 GB.
  • FIG. 11 is a diagram showing a configuration example of the event management table T30.
  • the event management table T30 manages events that have occurred in each device under the management of the management server 30.
  • the event management table T30 manages, for example, the event ID C300, device ID C301, part IDC302, parameter C303, status C304, processed flag C305, and date / time C306 in association with each other.
  • Event ID C300 is an event identifier. The occurrence of an event is determined based on a change in configuration information, as will be described later.
  • the device ID C301 is an identifier of a device (device) in which an event has occurred.
  • the part ID C302 is an identifier for specifying the part where the event has occurred in the apparatus.
  • the parameter C303 is the name of the parameter that has detected a change in configuration information.
  • a state C304 indicates the type of change in configuration information. Examples of status types include “change”, “add”, and “delete”.
  • the processed flag C305 indicates whether the event has been processed by the event propagation model expansion module P35 described later.
  • the date and time C306 is the date and time when the event occurred.
  • the management server 30 detects the change of the iSCSI initiator connectable to the iSCSI target (TG1) of the storage device 20 (SYS1) as an event (EV1).
  • an event propagation model for identifying the root cause in failure analysis is a combination of events that are expected to occur as a result of a failure (cause) and the root cause in the “IF-THEN” format. Describe.
  • FIGS. 12A and 12B In this embodiment, for convenience, two event propagation models will be described as shown in FIGS. 12A and 12B. In addition to the two, more event propagation models (rules) may be prepared.
  • the event propagation model manages, for example, the model ID C310, the observation event C311, and the cause C312 fields in association with each other.
  • Model ID C310 is an identifier of the event propagation model.
  • Observation event C311 indicates a plurality of related events observed as a result of a certain cause.
  • the observed event corresponds to the IF part of the event propagation model described in the “IF-THEN” format.
  • the cause C312 is a cause event among the observed events.
  • the cause event (cause event) corresponds to the THEN part of the event propagation model described in the “IF-THEN” format.
  • FIG. 12A shows an example of specific values of the event propagation model.
  • an event propagation model (Rule 1), when an ERROR of a logical volume on the host computer 10 and an ERROR of the I / O port 200 in the storage apparatus 20 are detected, a failure of the I / O port 200 of the storage apparatus 20 occurs. Conclude that it is the cause.
  • FIG. 13A, FIG. 13B, FIG. 13C, and FIG. 13D show the configuration of the causality matrix T32.
  • the causality matrix T32 defines a specific causal relationship of a failure event that occurs in each device of the computer system.
  • the causality matrix T32 manages, for example, the fields of the event propagation model ID C320, the observation event C321, the cause event C322, and the causal relationship C323 in association with each other.
  • Event propagation model ID C320 is an identifier of the event propagation model used for the deployment process.
  • an event (failure event) that can be received from each device to be managed by the state acquisition module P32 of the management server 30 is registered.
  • a cause event that the event analysis processing unit P34 concludes as a cause of failure when a failure event is received is registered.
  • the causal relationship C323 a correspondence relationship is registered which event is determined to be the root cause when which event is received.
  • FIG. 13A shows an example of specific values of the causality matrix T32. For example, if two events, ERROR of the volume (VOL1) of the storage device 20 (SYS1) and ERROR of the logical volume (E :) of the host 10 (HOST1), are detected, the volume of the storage device 20 (SYS1) ( VOL1) failure is determined to be the root cause.
  • FIG. 14 shows a configuration example of the topology generation method in the topology generation method repository T33.
  • the topology generation method defines a method of generating a connection relationship (topology) between devices to be managed based on configuration information acquired from each device to be managed.
  • the fields of the topology ID C330, the start component C331, the end component C332, the transit component C333, and the topology generation condition C334 are associated with each other and managed.
  • Topology ID C330 is a topology identifier.
  • the starting component C331 is a component type in the node device that is the starting point of the topology.
  • the end point component C332 is a component type in the node device that is the end point of the topology.
  • the route component C333 is a component type in the node device that is routed when generating a topology from the start component to the end component.
  • the topology generation condition C334 is a method for generating a topology between the starting component and the ending component.
  • FIG. 14A shows an example of specific values of the topology generation method T33.
  • FIG. 14A shows a topology starting from the logical volume of the host computer 10, starting from the I / O port 200 of the storage apparatus 20, and passing through the iSCSI target of the storage apparatus 20.
  • the topology can be acquired by searching for a combination in which the iSCSI initiator name of the logical volume is equal to the iSCSI target connection permitted iSCSI initiator and the iSCSI target ID in the I / O port 200 is equal to the ID in the iSCSI target. It is.
  • the process of acquiring configuration information will be described with reference to the flowchart of FIG.
  • the configuration information acquisition process is performed by the configuration information acquisition module P31 of the management server 30.
  • the step may be abbreviated as “S”.
  • the program control module P30 instructs the configuration information acquisition module P31 to execute the configuration information acquisition process at a predetermined timing.
  • the predetermined timing include when the program control module P30 is activated, or after a predetermined time has elapsed since the last configuration information acquisition process. Note that there is no need to strictly give an instruction every fixed period, and it is sufficient that the configuration information acquisition process is repeatedly executed.
  • the configuration information acquisition module P31 repeats the following S61-S66 for each device to be managed (S60). First, the configuration information acquisition module P31 instructs the management target device to transmit configuration information (S61). The configuration information acquisition module P31 determines whether or not there is a response from the management target device (S62).
  • the configuration information acquisition module P31 compares the acquired configuration information with the past configuration information stored in the configuration database T36 (S63). If there is no response for the configuration information from the managed device (S62: NO), the configuration information acquisition process is terminated.
  • the configuration information acquisition module P31 determines whether there is a difference between the acquired configuration information and the past configuration information stored in the configuration database T36 (S64). That is, it is determined whether the current configuration information is different from the past configuration information.
  • the configuration information acquisition module P31 converts the difference to an event and registers it in the event management table T30 (S65). Making an event means that a configuration with a difference is handled as an event.
  • the configuration information acquisition module P31 stores the configuration information (current configuration information) acquired in S62 in the configuration database T36 (S66).
  • the configuration information acquisition module P31 executes processing for confirming whether or not the event propagation model should be redeployed (S67).
  • the above is the configuration information acquisition process performed by the information acquisition module P31.
  • FIG. 15 a redeployment necessity confirmation process that does not include the features of the present embodiment will be described in order to clarify the difference from the present embodiment. That is, the flowchart of FIG. 15 is a comparative example.
  • the re-development necessity confirmation process is a process for determining whether to re-create the causality matrix by expanding the event propagation model.
  • the topology generation method corresponding to the event propagation model is acquired from the topology generation method repository (S22).
  • the topology generation method is acquired from the configuration database based on the topology generation method (S24). Further, the event propagation model is developed in the acquired topology and added to the causality matrix (S24).
  • a topology generation method (TP1) is defined in which the logical volume of the host computer is the starting component and the I / O port of the storage device is the ending component. Therefore, the topology is acquired using this topology generation method (TP1).
  • the iSCSI initiator name of the logical volume (E :) is “com.abc.sv1”.
  • the iSCSI target TG1 whose connection destination iSCSI initiator name is “com.abc.sv1” is searched.
  • the I / O port management table T22 shown in FIG. 9 the I / O port 200 (PORT1) whose iSCSI target ID is TG1 is searched.
  • the logical volume (E :) of the host computer 10 (HOST1) and the storage device 20 (SYS1) A combination of I / O ports 200 (PORT1) is detected.
  • causality matrix “ERROR of logical volume (E :) of host computer 10 (HOST1)” and “ERROR of I / O port 200 (PORT1) of storage device 20 (SYS1)” were detected as observation events. In this case, it is assumed that the cause is “failure of the I / O port 200 (PORT1) of the storage device 20 (SYS1)”.
  • the above processes S22-S24 are executed using all the logical volumes of the host computer 10 defined in the logical volume management table T10 as starting components.
  • the above is the event propagation model redeployment process as a comparative example.
  • the event propagation model is redeployed every time a configuration change of the managed device is detected. Therefore, when there are many devices managed by the management server 30 such as a large-scale data center, a large number of configuration changes occur, and the amount of data for managing the management target devices also increases. As a result, the process of redeploying the event propagation model is executed relatively frequently, and the processing load generated on the management server 30 increases.
  • the redeployment necessity confirmation process and the event propagation model redeployment process are improved based on an original idea.
  • FIG. 17 shows a deployment target event management table T34 specific to the present embodiment. Furthermore, a deployment target event propagation model management table T35 unique to this embodiment is shown in FIG. Furthermore, the operation of the management server 30 according to the present embodiment is shown in FIGS.
  • the deployment target event management table T34 may be manually defined by the administrator, or may be automatically generated by the method shown in the second embodiment to be described later.
  • FIG. 17 shows a configuration example of the deployment target event management table T34 as an example of “target event management information”.
  • the expansion target event management table T34 manages events that need to be expanded in the event propagation model.
  • the development target event management table T34 manages, for example, the device type C340, the component type C341, the parameter C342, the event type C343, and the event propagation model ID C344 in association with each other.
  • the device type C340 is a type of a device in which a configuration change event has occurred.
  • the component type C341 is the type of component in the device in which the configuration change event has occurred.
  • the parameter C342 is the name of a parameter for which a change in configuration information has been detected.
  • the event type C343 is a type of change in configuration information. Examples of the change in the configuration information include “addition”, “deletion”, and “change”. Events related to such configuration changes (addition, deletion, change) are referred to as configuration change events herein.
  • the event propagation model ID C344 is an identifier of an event propagation model to be applied to the configuration change event.
  • FIG. 17 shows an example of specific values of the development target event management table T34.
  • the event propagation model (Rule 1) is redeployed for the configuration change event.
  • the event propagation model is not redeployed.
  • FIG. 18 shows a configuration example of the deployment target event propagation model management table T35.
  • the deployment target event management table T35 defines an event propagation model to be deployed.
  • the expansion target event propagation model management table T35 has a field for registering which event propagation model is the expansion target.
  • FIG. 18 shows a specific example.
  • One event propagation model (Rule1) and another event propagation model (Rule2) are targets of redeployment.
  • FIG. 19 is a flowchart of the redeployment necessity confirmation process performed by the configuration information acquisition module P31.
  • the configuration information acquisition module P31 refers to the event management table T30 and checks whether there is an unprocessed event (S30).
  • An unprocessed event is an event indicating a configuration change, and is an event for which “NO” is set in the processed flag C305.
  • the configuration information acquisition module P31 repeats the processes S32 to S34 in the loop for the unprocessed event (S31).
  • the configuration information acquisition module P31 confirms whether an event of the same type as an unprocessed event is registered in the deployment target event management table T34 (S32).
  • the configuration information acquisition module P31 applies the rule defined in the expansion target event management table T34 that requires expansion. The event is registered in the event propagation model management table T35 (S33). Finally, the configuration information acquisition module P31 changes the processed flag C305 of the unprocessed event to “YES” (S34).
  • the configuration information acquisition module P31 instructs the event propagation model expansion module P35 to perform the event propagation model redeployment processing shown in FIG.
  • the above is the redeployment necessity confirmation process according to the present embodiment.
  • only events registered in the deployment target event management table T34 among events indicating configuration changes are subject to event propagation model redeployment processing. Therefore, the burden on the management server 30 can be reduced.
  • FIG. 20 shows a flowchart of the event propagation model redeployment process performed by the event propagation model development module P35.
  • the event propagation model expansion module P35 repeats the following series of processing S41 to S44 for all event propagation models defined in the expansion target event propagation model management table T35 (S40). If no ID is registered in the development target event propagation model management table T35, this process ends without performing the following processes S41 to S44.
  • the event propagation model expansion module P35 deletes all the causality matrix T32 having the ID of the target event propagation model (S41).
  • the event propagation model expansion module P35 refers to the topology generation method repository T33 and acquires the topology generation method corresponding to the target event propagation model from the topology generation method repository T33 (S42).
  • the event propagation expansion module P35 acquires the topology from the configuration database T36 based on the topology generation method.
  • the event propagation expansion module P35 applies the event propagation model to the topology and adds it as a column of the causality matrix T32 (S44).
  • the event propagation expansion module P35 determines the ID defined in the expansion target event propagation model management table T35 after the above processing S41-S44 is completed for all event propagation models defined in the expansion target event propagation model management table T35. Are all deleted (S45). The above is the event propagation model redeployment process.
  • the causality matrix T32 related to the event propagation model T31 (Rule1) at the start of processing is shown in FIG. 13A
  • the causality matrix T32 related to the event propagation model T31 (Rule2) is shown in FIG. 13C
  • the RAID group management table T23 is shown in FIG. Table T21 is as shown in FIG. 8A.
  • the program control module P30 instructs the configuration information acquisition module P31 to execute the configuration information acquisition process according to an instruction from the administrator or a schedule setting by a timer.
  • the configuration information acquisition module P35 instructs to log in to each managed device in order and transmit configuration information corresponding to the type of the device.
  • the configuration information acquisition module P35 compares the past configuration information stored in the configuration database T36 with the current configuration information acquired from each managed device, and creates an event management table T30. Update.
  • the configuration information acquisition module P31 performs the following processing on the events defined in the event management table T30. First, the configuration information acquisition module P31 refers to the development target event management table T34 and checks whether an event of the same type as the event registered in the event management table T30 is defined.
  • the same type means that the device type, the component type in the device, the parameter name, and the state change type are all equal.
  • the configuration information acquisition module P31 uses the rules (event propagation model) defined in the event propagation model ID C344 of the deployment target event management table T34 as the deployment target event propagation model. Register in the management table T35.
  • “change of iSCSI initiator permitted to connect to iSCSI target of storage device” is defined as one of the types of events that need to be redeployed.
  • the configuration information acquisition module P31 registers the event propagation model ID (Rule1) corresponding to the event type in the deployment target event propagation model management table T35.
  • the configuration information acquisition module P31 instructs the event propagation model expansion module P35 to perform the event propagation model redeployment process.
  • the event propagation model expansion module P35 refers to the expansion target event propagation model management table T35 and performs reexpansion processing on Rule1 registered in the expansion target event propagation model management table T35.
  • the event propagation model expansion module P35 deletes the column in which the event propagation model ID is Rule1 from the causality matrix T32.
  • the event propagation expansion module P35 expands the event propagation model (Rule1) and adds it to the causality matrix T32.
  • the unfolding method is the same as the method described in FIG.
  • the causality matrix T32 related to the event propagation model (Rule1) is updated and changes from the state shown in FIG. 13A to the state shown in FIG. 13B.
  • FIG. 7B shows the volume management table T20 after the change.
  • the following processing is executed for the event related to the configuration change defined in the event management table T30.
  • the development target event management table T34 is referred to, and it is confirmed whether or not an event of the same type as the event defined in the event management table T30 is defined in the management table T34.
  • the event propagation model (rule) defined in the event propagation model ID C344 in the deployment target event management table T34 is registered in the deployment target event propagation model management table T35. Is done.
  • “change of RAID group ID related to storage device volume” is defined as the type of event that needs to be redeployed.
  • the configuration information acquisition module P31 registers Rule2, which is the event propagation model ID corresponding to the event type, in the deployment target event propagation model management table T35.
  • the configuration information acquisition module P31 instructs the event propagation model expansion module P35 to perform the event propagation model redeployment process.
  • the event propagation model expansion module P35 refers to the expansion object event propagation model management table T35 and performs reexpansion processing for Rule2 registered in the expansion object event propagation model management table T35.
  • the column whose event propagation model ID is Rule2 is deleted from the causality matrix T32.
  • the event propagation model (Rule2) is expanded and added to the causality matrix T32.
  • the unfolding method is the same as the method described in FIG.
  • the causality matrix T32 related to the event propagation model (Rule2) is updated and changes from the state shown in FIG. 13C to the state shown in FIG. 13D.
  • an event propagation model that needs to be redeployed is identified for each configuration change event, and only the event propagation model that needs to be redeployed is deployed. To do. Therefore, in this embodiment, useless redeployment processing can be suppressed and the processing load on the management server 30 can be reduced.
  • a second embodiment will be described with reference to FIGS.
  • This embodiment corresponds to a modification of the first embodiment. Therefore, the difference from the first embodiment will be mainly described.
  • the event propagation model expansion module P35 automatically generates the expansion target event management table T34.
  • a deployment module P35 it may be referred to as a deployment module P35.
  • the process for generating the deployment target event management table T34 can be executed at a predetermined timing. For example, when the management server 30 is started for the first time, a new event propagation model is added to the event propagation model repository T31, or a part of the event propagation model in the event propagation model repository T31 is deleted, for example, And so on.
  • the expansion module P35 repeats the following series of processes S51-S53 for all event propagation models defined in the event propagation model repository T31 (S50).
  • the expansion module P35 refers to the topology generation method repository T33 and acquires the topology generation method for generating the event propagation model repository T31 (S51).
  • the deployment module P35 extracts all the components described in the start point component, end point component, and route component from the topology generation method (S52). Further, the expansion module P35 adds each extracted component and event propagation model ID to the expansion target event propagation model management table T34 (S52). In this case, the expansion module P35 sets the event type to “addition / deletion” and does not specify a parameter.
  • the expansion module P35 extracts all the components and parameters described in the topology generation condition (S53). Furthermore, the expansion module P35 adds each computer and each parameter together with the event propagation model ID to the expansion target event propagation model management table T34 (S53). In this case, the expansion module P35 sets the event type to “change”.
  • the following is a specific example of deployment target event management table generation processing.
  • the deployment module P35 acquires the topology generation method used for generating the event propagation model from the topology generation method repository T33 for the event propagation model defined in the event propagation model repository T31.
  • the expansion module P35 extracts all the components described in the start point component, the end point component, and the transit component from the topology generation method, and adds them to the expansion target event propagation model management table T35.
  • the event propagation model (Rule 1) is composed of a logical volume of the host computer 10 and an I / O port of the storage apparatus 20. Therefore, in order to acquire the topology for the event propagation model (Rule1), the topology generation method (TP1) shown in FIG. 14A is used.
  • the starting component is the logical volume of the host computer 10
  • the end component is the I / O port of the storage device 20
  • the transit component is the iSCSI target of the storage device 20. Therefore, as shown in FIG. 17, each component is added to the development target event management table T34.
  • “addition / deletion” is set as the value of the event type C343.
  • “Rule1” is set as the value of the application rule ID (event propagation model ID) C344.
  • the expansion module P35 extracts all components and parameters described in the topology generation condition C334 of the topology generation method, and adds them to the expansion target event propagation model management table T34.
  • the components and parameters described in the topology generation condition C334 of the topology generation method (TP1) include the iSCSI initiator name of the logical volume, the iSCSI initiator permitted to connect to the iSCSI target, and the iSCSI target ID of the I / O port 200. , ISCSI target ID. Therefore, the expansion module P35 adds them to the expansion target event management table T34.
  • the event type C343 is set to “change”, and the application rule ID (event propagation model ID C344) is set to Rule1.
  • the development target event management table T34 is generated, and the state shown in FIG. 17 is obtained.
  • the deployment target event management table T34 can be generated based on the event propagation model registered in the event propagation model repository T31.
  • the deployment target event management table T34 can be automatically updated. Therefore, it is possible to appropriately generate the causality matrix while reducing the processing load on the management server 30. Furthermore, since the deployment target event management table T34 can be automatically generated, it is possible to save the administrator's trouble.
  • FIG. 23 is an overall conceptual diagram schematically showing the relationship between processing and management information according to the present embodiment.
  • the management server 30 refers to the event propagation model T31 and the topology generation method T33 in the expansion target event management table generation process (FIG. 21), and generates the expansion target event management table T34.
  • the expansion target event management table T34 manages the correspondence relationship between the event that is the result of the configuration change and the event propagation model to be redeployed when the event occurs.
  • the management server 30 refers to the event management table T30 and confirms whether there is an unprocessed event.
  • the management server 30 refers to the deployment target event management table T34 and identifies an event propagation model that needs to be redeployed for the unprocessed event.
  • the management server 30 executes the event propagation model redeployment process only for the identified event propagation model.
  • 1st Embodiment and 2nd Embodiment can also be expressed as a computer program as follows.
  • a computer program for causing a computer to function as a management device for managing a computer system including a plurality of node devices The storage device provided in the computer stores at least one predetermined analysis rule, target event management information for managing a correspondence relationship between the event that can be detected by the management device and the predetermined analysis rule,
  • the predetermined analysis rule defines a relationship between a cause event causing a failure and a related event indicating a failure caused by the cause event, A function of monitoring each node device; A function of determining whether the event is registered in the target event management information when a configuration change of each node device is detected as an event; A function for executing a predetermined process when the detected event is registered in the target event management information;

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Debugging And Monitoring (AREA)

Abstract

計算機システムの構成が変化を示すイベントが検出された場合、必要なイベントについてのみ障害解析に用いるための情報を生成すること。　管理装置は、計算機システムの構成変化をイベントとして検出し、イベント管理表Ｔ３０に記録する。管理装置は、障害を解析するためのイベント伝播モデルを保持しており、イベント伝播モデルに対応するイベントを対象イベント管理情報Ｔ３４に記録する。管理装置は、検出されたイベントが対象イベント管理情報に登録されている場合に、障害解析処理を実行する。

Description

計算機システムの管理方法及び管理装置
　本発明は、計算機システムの管理方法及び管理装置に関する。
　多数のノード装置を有する計算機システムを管理する管理ソフトウェアは、障害または障害の予兆を検出すると、それらの中から原因となる事象を推定する（特許文献１）。より具体的には、特許文献１に記載の管理ソフトウェアは、管理対象の各装置で生じる各種障害をイベント化し、イベントデータベースにイベント情報を蓄積する。管理ソフトウェアは、解析エンジンを有する。解析エンジンは、管理対象装置に発生した複数の障害イベントの因果関係を解析する。
　解析エンジンは、管理対象装置のインベントリ情報を持つ構成データベースにアクセスして、I/O（Input/Output）系路上にある装置内構成要素を「トポロジ」と呼ばれる一つのグループとして認識する。解析エンジンは、そのトポロジに障害伝播モデルを適用して、因果律行列を構築する。
　障害伝播モデルは、事前に定められた、条件文及び解析結果から構成される。因果律行列には、原因となる障害を示す原因イベントと、原因イベントにより引き起こされている障害を示す関連イベント群とが含まれる。具体的には、ルールのTHEN部に、障害の根本原因として記載されているイベントが原因イベントである。ルールのIF部に記載されているイベントのうち原因イベント以外のものが関連イベントである。
米国特許第７１０７１８５号明細書
　計算機システム内の或る装置において障害が発生すると、その障害が原因となり、障害の発生した装置に接続された他の一つまたは複数の装置でも別の障害が発生する。この結果、計算機システム内で複数の障害が発見される。
　ホストコンピュータ、ネットワーク装置、ストレージ装置のような種々のノード装置を管理する管理ソフトウェアは、障害解析機能を有する。管理ソフトウェアは、解析機能を用いて、複数の障害のうち根本原因となる障害を管理者に提示する。
　障害解析機能を実現するための障害解析エンジンは、障害解析ノウハウに基づき定義された複数のイベント伝播モデルを持つ。管理ソフトウェアは、ノード装置の構成情報から装置間のトポロジを取得し、そのトポロジにイベント伝播モデルを当てはめる。管理ソフトウェアは、装置で生じた障害イベントと、その障害の根本原因となるイベントとの対応関係を表す、因果律行列を出力する。障害解析エンジンは、因果律行列を記憶領域に保持し、障害解析に利用する。
　計算機システムは、種々の理由で、新たなノード装置が追加されたり、既存のノード装置が取り外されたり、ノード装置の設定が変更されたりする。このように、計算機システムの構成は変化する。管理ソフトウェアは、保持している構成情報の変更を検知する度に、因果律行列を破棄する。管理ソフトウェアは、最新のトポロジに基づいてイベント伝播モデルを展開し、最新の構成に対応する因果律行列を新たに作成する。以後、計算機システムの構成が変化する度に、イベント伝播モデルの展開処理が実行される。
　しかし、管理ソフトウェアが検知する構成変更の中には、イベント伝播モデルを再展開する必要のない構成変更も含まれていると考えられる。従来技術では、イベント伝播モデルの再展開が不要な構成変更であっても、イベント伝播モデルを再展開しているため、管理ソフトウェアの処理負荷が増大する。例えば、大規模なデータセンタ等のような計算機システムでは、ノード装置の数が多いため、修理又は点検、増設または減設のために、比較的頻繁に構成が変化する。
　本発明は、上記の問題に鑑みてなされたもので、管理のための処理負荷を軽減できるようにした計算機システムの管理方法及び管理装置を提供することにある。
　本発明の一つの観点に係る計算機システムを管理する方法では、計算機システムは、複数のノード装置と、複数のノード装置を管理するための管理装置とを含んでいる。管理装置は、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とを保持している。所定の解析ルールは、障害の発生原因となる原因イベントと、原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義している。管理装置は、各ノード装置の構成変化をイベントとして検知した場合、そのイベントが対象イベント管理情報に登録されているか否かを判定し、検知されたイベントが対象イベント管理情報に登録されている場合に、所定の処理を実行するようになっている。
　管理装置は、複数のノード装置から構成情報を取得し、所定の処理は、検知されたイベントと対象イベント管理情報に基づいて処理すべき解析ルールを特定し、特定された解析ルールを構成情報に適用して、障害解析のための情報を生成する処理であってもよい。例えば、計算機システムの具体的な構成に所定の解析ルールを当てはめて、障害を解析するための具体的な情報（例えば後述の因果律行列）を生成してもよい。
　管理装置は、所定の解析ルールの内容に基づいて、対象イベント管理情報を作成して保持してもよい。
　管理装置は、各ノード装置間の接続関係を示すトポロジを生成するためのトポロジ生成方法を複数記憶するトポロジ生成情報を保持しており、所定の解析ルールに対応する所定のトポロジ生成方法をトポロジ生成情報から取得し、取得された所定のトポロジ生成方法に規定されているノード装置を、イベントの発生元として対象イベント管理情報に登録することにより、対象イベント管理情報を作成して保持してもよい。
　管理装置は、所定のタイミングで、対象イベント管理情報を作成して保持するようになっており、所定のタイミングとは、管理装置が初めて起動した場合、または、新しい所定の解析ルールが追加された場合、または、既存の所定の解析ルールが削除または変更された場合、の少なくともいずれか一つの場合であってもよい。
　各ノード装置のいずれかにおいて障害が検出された場合、障害解析のための情報に基づいて、検出された障害の原因を推定してもよい。
　本発明は、計算機システムの管理方法、計算機システムを管理するためのコンピュータプログラムとして捉えることもできる。
計算機システムの物理構成例を示す図である。 ホストコンピュータの構成例を示す図である。 ストレージ装置の構成例を示す図である。 管理サーバの構成例を示す図である。 IPスイッチの構成例を示す図である。 論理ボリューム管理表の構成例を示す図である。 論理ボリューム管理表の他の例を示す図である。 論理ボリューム管理表のさらに他の例を示す図である。 ボリューム管理表の構成例を示す図である。 ボリューム管理表の他の例を示す図である。 iSCSIターゲット管理表の構成例を示す図である。 iSCSIターゲット管理表の他の例を示す図である。 I/Oポート管理表の構成例を示す図である。 RAIDグループ管理表の構成例を示す図である。 イベント管理表の構成例を示す図である。 イベント伝播モデルの構成例を示す図である。 イベント伝播モデルの他の例を示す図である。 因果律行列の構成例を示す図である。 因果律行列の他の例を示す図である。 因果列行列のさらに他の例を示す図である。 因果列行列のさらに別の例を示す図である。 トポロジ生成方式の構成例を示す図である。 トポロジ生成方式の他の例を示す図である。 比較例としての再展開要否確認処理のフローチャートである。 比較例としてのイベント伝播モデル再展開処理のフローチャートである。 展開対象イベント管理表の構成例を示す図である。 展開対象イベント伝播モデル管理表の構成例を示す図である。 再展開要否確認処理のフローチャートである。 イベント伝播モデル再展開処理のフローチャートである。 展開対象イベント管理表生成処理のフローチャートである。 構成情報取得処理のフローチャートである。 管理サーバが実施する処理の全体概念図である。
　以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。
　本実施形態では、構成変更イベントが発生する毎に、再展開が必要なイベント伝播モデルを特定し、再展開が必要なイベント伝播モデルについてのみ展開を行なう。展開要否の判断には、展開対象イベント管理表を用いる。展開対象イベント管理表は、例えば、構成変更イベントのうち再展開処理が必要なイベントの種別と、再展開すべきイベント伝播モデルとを対応付けて定義する。
　本実施形態によれば、イベント伝播モデルの再展開処理が必要な構成変更イベントについてのみ、イベント伝播モデル再展開処理を実施できる。従って、システムを管理する処理の負荷を軽減できる。
　さらに、本実施形態では、管理者がイベント伝播モデルを追加もしくは削除した場合、展開対象イベント管理表の内容は自動的に更新される。
　なお、本明細書では、実施形態において使用される情報を、「ａａａ表」という表現で説明しているが、これに限らず、例えば、「ａａａリスト」、「ａａａデータベース」、「ａａａキュー」等の他の表現を用いてもよい。本実施形態で用いられる情報が、データ構造に依存しないことを示すために、「ａａａ情報」と呼ぶこともある。
　本実施形態で使用される情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ID」という表現を用いることがあるが、これらは互いに置換が可能である。
　さらに、本実施形態の処理動作の説明では、「コンピュータプログラム」または「モジュール」を動作主体（主語）として説明することがある。プログラムまたはモジュールは、マイクロプロセッサによって実行される。プログラムまたはモジュールは、定められた処理を、メモリ及び通信ポート（通信制御装置）を用いながら実行する。従って、プロセッサを動作主体（主語）として読み替えても良い。
　プログラムまたはモジュールを主語として開示された処理は、管理サーバ等の計算機等が行う処理として読み替えてもよい。さらに、コンピュータプログラムの一部または全ては、専用ハードウェアによって実現されてもよい。コンピュータプログラムは、プログラム配布サーバまたは記憶メディアによって計算機にインストールされてもよい。
　図１～図５は、計算機システムの全体構成および計算機システムに接続される各装置の構成を示す。図６～図１４は、各装置の備える管理用の情報を示す。
　図１は、計算機システムの物理的構成を示す図である。計算機システムは、例えば、ホストコンピュータ１０と、ストレージ装置２０と、管理サーバ３０と、IPスイッチ４０と、ウェブサーバ５０と、を有する。各装置１０，２０，３０，４０，５０は、通信ネットワーク６０によって通信可能に接続されている。
　ホストコンピュータ１０（１），１０（２）は、例えば、図示しないクライアントコンピュータからファイルのI/O要求を受信し、そのI/O要求に基づいてストレージ装置２０（１），２０（２）にアクセスする。管理サーバ（管理計算機）３０は、計算機システム全体の運用を管理する。なお、特に区別する必要がない場合、ホストコンピュータ１０（１），１０（２）をホストコンピュータ１０と呼び、ストレージ装置２０（１），２０（２）をストレージ装置２０と呼ぶ。
　ウェブサーバ５０は、通信ネットワーク６０を介して、管理サーバ３０のGUI（Graphical
User Interface）表示処理モジュールＰ３３と通信し、WEBブラウザに各種情報を表示させる。ユーザは、ウェブサーバ５０のWEBブラウザに表示された情報を参照することで、計算機システム内の各装置１０，２０，４０を管理する。
　なお、ウェブサーバ５０に代えて、携帯電話または携帯情報端末のような携帯型の計算機を用いて、管理サーバ３０の提供する情報を参照したり、管理サーバ３０に指示を与えたりする構成でもよい。管理サーバ３０とウェブサーバ５０とを一つのサーバに設ける構成でもよい。さらに、ホストコンピュータ１０に、管理サーバ３０の機能およびウェブサーバ５０の機能のうち少なくともいずれか一方の機能を設ける構成でもよい。
　図２は、ホストコンピュータ１０の内部構成例を示す。ホストコンピュータ１０は、例えば、通信ポート１００と、プロセッサ（図中ＣＰＵ）１１０と、メモリ１２０と、を備える。これら１００，１１０，１２０は、内部バス等を介して接続される。
　通信ポート（以下、ポート）１００は、通信ネットワーク６０を介して通信するための回路である。プロセッサ１１０は、メモリ１２０に記憶された各種コンピュータプログラムを読み込んで実行する。
　メモリ１２０には、例えば、アプリケーションプログラムＰ１１と、オペレーティングシステムＰ１０と、論理ボリューム管理表Ｔ１０と、が格納される。メモリ１２０には、例えば、フラッシュメモリデバイスまたはハードディスクドライブのような記憶装置を含めてもよい。
　アプリケーションプログラムＰ１１は、オペレーティングシステムＰ１０から提供された記憶領域を使用して、その記憶領域にデータを入出力する。アプリケーションプログラム（アプリケーションと略記する場合もある）Ｐ１０は、例えば、顧客管理プログラム、売上げ管理プログラム、動画像配信プログラムなどのように構成され、図外のクライアントコンピュータにサービスを提供する。
　オペレーティングシステムＰ１０は、ホストコンピュータ１０に接続されたストレージ装置２０の論理ボリューム２３２（図３参照）を記憶領域として、アプリケーションプログラムＰ１１に認識させる。
　図２では、I/Oポートと管理ポートの両方を含むポート１００として表現しているが、I/Oポートと管理ポートとを別々に設ける構成でもよい。I/Oポートとは、ストレージ装置２０とiSCSIにより通信を行うための通信ポートである。管理ポートとは、管理サーバ３０がホストコンピュータ１０内の管理情報を取得するための通信ポートである。
　図３は、ストレージ装置２０の内部構成例を示す。ストレージ装置２０は、例えば、I/Oポート２００（１），２００（２）と、管理ポート２０１と、コントローラ２１０（１），２１０（２）と、管理メモリ２２０と、記憶装置２３０とを備える。これら２００，２０１，２１０，２２０，２３０は、内部バス等で接続される。
　I/Oポート２００（１），２００（２）は、通信ネットワーク６０を介してホストコンピュータ１０に接続するための通信ポートである。区別しない場合、I/Oポート２００と呼ぶ。管理ポート２０１は、通信ネットワーク６０を介して管理サーバ３０に接続するための通信ポートである。
　コントローラ２１０（１），２１０（２）は、ストレージ装置２０の動作を制御するための装置である。区別しない場合、コントローラ２１０（１），２１０（２）をコントローラ２１０と呼ぶ。
　各コントローラ２１０は、その内部に、ストレージ装置２０の動作を制御するためのプロセッサと、ホストコンピュータ１０との間で送受信するデータを一時的に記憶するキャッシュメモリとを備える。各コントローラ２１０は、I/Oポート２００とRAIDグループ２３１の間に介在し、両者の間でデータを受け渡す。
　コントローラ２１０は冗長構成を備えており、いずれか一方のコントローラが停止した場合でも、他方のコントローラがストレージ装置２０の制御を受け継ぐことができる。
　RAIDグループ２３１は、１つまたは複数の記憶装置２３０を含む。複数の記憶装置２３０のそれぞれ有する物理的記憶領域をRAID構成として、RAIDグループ２３１を生成することもできる。RAIDグループ２３１には、論理的な記憶領域である、論理ボリューム２３２を一つ以上設けることができる。
　論理ボリューム２３２は、１つの記憶装置２３０の持つ物理的記憶領域に基づいて生成することもできる。この場合、その物理的記憶領域は、RAID構成である必要はない。
　記憶装置２３０としては、例えば、ハードディスクデバイス、半導体メモリデバイス、光ディスクデバイス、光磁気ディスクデバイス等のデータを読み書き可能な種々の記憶装置を利用可能である。
　記憶装置２３０としてハードディスクデバイスを用いる場合、例えば、ＦＣ（Fibre Channel）ディスク、ＳＣＳＩ（Small Computer System Interface）ディスク、ＳＡＴＡディスク、ＡＴＡ（AT Attachment）ディスク、ＳＡＳ（Serial Attached SCSI）ディスク等を用いることができる。
　また、例えば、フラッシュメモリ、ＦｅＲＡＭ（Ferroelectric Random Access Memory）、ＭＲＡＭ（MagnetoresistiveRandom Access Memory）、相変化メモリ（Ovonic Unified Memory）、ＲＲＡＭ（Resistance RAM）等の種々の記憶装置を用いることもできる。さらに、例えば、フラッシュメモリデバイスとハードディスクデバイスのように、種類の異なる記憶装置を混在させる構成でもよい。
　管理メモリ２２０には、例えば、ストレージ装置を管理する管理プログラムＰ２０と、ボリューム管理表Ｔ２０と、iSCSIターゲット管理表Ｔ２１と、I/Oポート管理表Ｔ２２と、RAIDグループ管理表Ｔ２３と、が格納される。各管理表Ｔ２０，Ｔ２１，Ｔ２２，Ｔ２３の詳細は後述する。
　管理プログラムＰ２０は、管理ポート２０１を経由して管理サーバ３０と通信し、管理サーバ３０にストレージ装置２０の構成情報を提供する。
　なお、ストレージ装置２０は、図３に示す構成に限らない。ストレージ装置２０は、ストレージコントローラと、記憶装置を備えていればよい。ストレージコントローラは、例えば、ホストコンピュータ１０に論理ボリュームを提供する機能と、ホストコンピュータ１０からのアクセス要求（I/O要求）に基づいてデータを読み書きする機能と、データを一時的に記憶する機能を備えていればよい。ストレージコントローラと記憶装置とは同一筐体に設けられている必要はなく、それぞれ別々の筐体に設けられてもよい。なお、ストレージ装置２０をストレージシステムと呼び変えてもよい。
　図４は、管理サーバ３０の内部構成例を示す。管理サーバ３０は、例えば、管理ポート３００と、プロセッサ３１０と、メモリ３２０と、二次記憶領域３３０と、出力装置３４０と、入力装置３５０とを有し、これら３００－３５０が内部バス等の回路を介して相互に接続されている。
　管理ポート３００は、通信ネットワーク６０を介して管理サーバ３０と通信する回路である。プロセッサ３１０は、後述する各ソフトウェアモジュールＰ３０－Ｐ３５を読み込んで実行する。出力装置３４０は、例えば、ディスプレイ、プリンタ、スピーカー等から構成される。出力装置３４０は、後述の処理結果を出力する。入力装置３５０は、例えば、キーボード、マウス、タッチパネル、マイクロフォン等から構成される。管理者（ストレージ管理者）は、入力装置３５０を介して、管理サーバ３０に指示を与える。
　メモリ３２０には、例えば、プログラム制御モジュールＰ３０と、構成情報取得モジュールＰ３１と、状態取得モジュールＰ３２と、GUI表示処理モジュールＰ３３と、イベント解析処理モジュールＰ３４と、イベント伝播モデル展開モジュールＰ３５と、が格納されている。各モジュールの詳細は後述する。図中では、便宜上、モジュールの名称を一部省略して表示することがある。例えば、イベント解析処理モジュールＰ３４は、図中では、イベント解析モジュールとして表示されている。
　なお、図４では、各モジュールは、メモリ３２０に記憶されるソフトウェアモジュールとして提供されているが、これに代えて、各モジュールをハードウェアモジュールとして生成してもよい。さらに、各モジュールの行う処理が一つ以上のプログラムコードとして提供されても良い。さらに、モジュール間の明確な境界が存在しなくても良い。
　二次記憶領域３３０には、例えば、イベント管理表Ｔ３０と、イベント伝播モデルリポジトリＴ３１と、因果律行列Ｔ３２と、トポロジ生成方式リポジトリＴ３３と、展開対象イベント管理表Ｔ３４と、展開対象イベント伝播モデル管理表Ｔ３５と、構成データベースＴ３６と、が格納されている。説明の便宜上、イベント伝播モデルに符号Ｔ３１を付したり、トポロジ生成方式に符号Ｔ３３を付したりする場合がある。
　構成データベースＴ３６には、構成情報取得モジュールＰ３１が収集した各構成情報が記憶される。構成情報には、ホストコンピュータ１０から取得される情報と、ストレージ装置２０から取得される情報とがある。ホストコンピュータ１０から取得される情報には、論理ボリューム管理表Ｔ１０がある。ストレージ装置２０から取得される情報には、ボリューム管理表Ｔ２０と、iSCSIターゲット管理表Ｔ２１と、I/Oポート管理表Ｔ２２と、RAIDグループ管理表Ｔ２３がある。
　二次記憶領域３３０は、例えば、フラッシュメモリデバイスまたはハードディスクドライブのいずれか一つまたは両方から構成することができる。二次記憶領域３３０に代えて、各管理表Ｔ３０－Ｔ３６をメモリ３２０に記憶させてもよい。二次記憶領域３３０に記憶されている管理表Ｔ３０－Ｔ３６の一部をメモリ３２０に記憶させてもよい。
　状態取得モジュールＰ３２は、管理対象の各ノード装置（ホストコンピュータ１０，ストレージ装置２０）に定期的にアクセスし、各ノード装置内の各コンポーネントの状態を取得する。
　イベント解析処理モジュールＰ３４は、因果律行列Ｔ３２を参照し、状態取得モジュールＰ３２が取得したノード装置の異常状態の、根本原因を解析する。
　GUI表示処理モジュールＴ３３は、入力装置３５０を介した管理者からの要求に応じ、各ノード装置から取得した構成情報を、出力装置３４０を介して表示する。入力装置３５０と出力装置３４０とは別々な装置でもよいし、または、一つ以上のまとまった装置として構成されてもよい。
　なお、管理サーバ３０は、１つのコンピュータから構成してもよいし、複数のコンピュータから構成してもよい。さらに、出力装置３４０及び入力装置３５０の代わりに、管理サーバ３０に表示用計算機を接続してもよい。表示用計算機は、入力装置及び出力装置を備える。管理者は、表示用計算機を介して、管理サーバ３０から情報を取得したり、管理サーバ３０に指示を与えたりすることができる。表示用計算機と管理サーバ３０とは、例えば、無線または有線で接続される。表示用計算機は、パーソナルコンピュータ、携帯電話、携帯情報端末として構成できる。
　本明細書では、計算機システム（情報処理システム）を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は、管理サーバが管理システムである。管理サーバと表示用計算機（例えばウェブサーバ５０）の組み合わせも、管理システムである。管理処理の高速化または高信頼化のために複数の計算機で、管理サーバと同等の処理を実現してもよい。この場合は、それら複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含めて）が、管理システムである。
　図５は、IPスイッチ４０の構成を示す。IPスイッチ４０は、例えば、プロセッサ４１０と、メモリ４２０と、I/Oポート４００（１），４００（２）と、管理ポート４０１とを備え、これら４１０，４２０，４００，４０１は、内部バス等を介して相互に接続されている。
　メモリ４２０には、例えば、制御プログラム及び各種管理情報（いずれも不図示）が格納される。プロセッサ４１０は、制御プログラムを実行して、IPスイッチ４０の動作を制御する。I/Oポート４００（１），４００（２）は、通信ネットワーク６０を介してホストコンピュータ１０に接続される。管理ポート４０１は、通信ネットワーク６０を介して、管理サーバ３０に接続される。
　図６Ａ、図６Ｂ及び図６Ｃは、論理ボリューム管理表Ｔ１０の構成例を示す。論理ボリューム管理表Ｔ１０は、ホストコンピュータ１０の使用する論理ボリュームを管理するための情報である。
　論理ボリューム管理表Ｔ１０は、例えば、ドライブ名Ｃ１００と、iSCSIイニシエータ名Ｃ１０１と、接続先iSCSIターゲットＣ１０２と、LUN
ID　Ｃ１０３の各フィールドを対応付けて管理する。
　ドライブ名Ｃ１００は、ホストコンピュータ１０内で各論理ボリューム２３２の識別子となるドライブ名を登録するためのフィールドである。iSCSIイニシエータ名Ｃ１０１は、iSCSIイニシエータ名を登録するフィールドである。iSCSIイニシエータは、論理ボリューム２３２の実体が存在するストレージ装置２０との通信に用いられる、ホストコンピュータ１０のI/Oポート１００の識別子である。接続先iSCSIターゲットＣ１０２は、論理ボリューム２３２の実体が存在するストレージ装置２０との通信に用いる、ストレージ装置２０のI/Oポート２００の識別子である。LUN ID　Ｃ１０３は、ストレージ装置において論理ボリューム２３２の識別子となるLUN（Logical Unit
Number） IDを登録するフィールドである。
　図６Ａは、論理ボリューム管理表Ｔ１０の具体的な値の一例を示す。図６Ａの第１行目には、ホストコンピュータ上で（E:）というドライブ名で示される論理ボリュームが記載されている。その論理ボリューム（E:）は、「com.abc.sv1」というiSCSIイニシエータ名で示されるホストコンピュータ上のポート１００と、「com.abc.sto1」というiSCSIターゲット名で示されるストレージ装置上のポート２００とを介して、ストレージ装置２０と接続されている。その論理ボリューム（E:）には、「0」というLUN IDがストレージ装置上で与えられている。
　図７Ａ及び図７Ｂは、ボリューム管理表Ｔ２０を示す図である。ボリューム管理表Ｔ２０は、ストレージ装置２０内の各論理ボリューム２３２を管理する。
　ボリューム管理表Ｔ２０は、例えば、ボリュームID　Ｃ２００と、容量Ｃ２０１と、RAIDグループID　Ｃ２０２と、ターゲットID　Ｃ２０３と、LUN ID　Ｃ２０４の各フィールドを対応付けて管理する。
　ボリュームID　Ｃ２００は、ストレージ装置２０の各論理ボリューム２３２の識別子である。  容量Ｃ２０１は、各ボリューム２３２の容量である。RAIDグループID　Ｃ２０２は、各ボリューム２３２の属するRAIDグループ２３１の識別子である。ターゲットID　Ｃ２０３は、各ボリューム２３２の属するiSCSIターゲットの識別子である。LUN ID　Ｃ２０４は、各ボリューム２３２のiSCSIターゲット内における識別子である。
　図７Ａには、ボリューム管理表Ｔ２０の具体的な値の一例が示されている。例えば、第１行目に着目すると、ボリューム２３２（VOL1）は、20GBの記憶領域を持ち、RAIDグループ２３１（RG1）に属する。さらに、そのボリューム２３２（VOL1）は、iSCSIターゲットID（TG1）で特定されるiSCSIターゲットに属し、LUN ID（0）を持つ。
　図８Ａ及び図８Ｂは、iSCSIターゲット管理表Ｔ２１を示す。iSCSIターゲット管理表Ｔ２１は、ストレージ装置２０内のiSCSIターゲットを管理する。iSCSIターゲット管理表Ｔ２１は、例えば、ターゲットID　Ｃ２１０と、iSCSIターゲット名Ｃ２１１と、接続許可iSCSIイニシエータＣ２１２の各フィールドを対応付けて管理する。
　ターゲットID　Ｃ２１０は、iSCSIターゲットの識別子である。iSCSIターゲット名C21１は、各iSCSIターゲットが持つiSCSIターゲット名である。接続許可iSCSIイニシエータＣ２１２は、iSCSIターゲットに接続が許可されたiSCSIイニシエータの名称である。つまり、フィールドＣ２１２には、iSCSIターゲットに属する論理ボリューム２３２に対してアクセスが許可された、ホストコンピュータ１０のポート１００の識別子となるiSCSIイニシエータ名が登録されている。
　図８Ａには、iSCSIターゲット管理表Ｔ２１の具体的な値の一例が示されている。第１行目に着目すると、ストレージ装置２０のiSCSIターゲット（HG1）は、「com.abc.sto1」というiSCSIターゲット名を持つ。さらに、そのiSCSIターゲット（HG1）は、iSCSIイニシエータ名が「com.abc.sv1」もしくは「com.abc.sv11」である、ホストコンピュータ１０のポート１００からのアクセスを許可している。
　図９は、I/Oポート管理表Ｔ２２の構成を示す。I/Oポート管理表Ｔ２２は、ストレージ装置２０のI/Oポート２００を管理する。I/Oポート管理表Ｔ２２は、例えば、ポートID　Ｃ２２０と、ターゲットID　Ｃ２２１との各フィールドを対応付けて管理する。
　ポートID　Ｃ２２０は、ストレージ装置２０の各ポート２００の識別子である。ターゲットID　Ｃ２２１は、ポート２００の通信ネットワーク６０上での識別子となるMACアドレスである。
　図９には、I/Oポート管理表の具体的な値の一例が示されている。第１行目に着目すると、ストレージ装置２０のポート２００（PORT1）は、TG1,TG2というiSCSIターゲットIDで特定されるiSCSIターゲットによって、使用されている。
　図１０は、RAIDグループ管理表Ｔ２３の構成を示す。RAIDグループ管理表Ｔ２３は、ストレージ装置２０内の各RAIDグループ２３１を管理する。RAIDグループ管理表Ｔ２３は、例えば、RAIDグループID　Ｃ２３０と、RAIDレベルＣ２３１と、容量Ｃ２３２の各フィールドを対応付けて管理する。
　RAIDグループID　Ｃ２３０は、各RAIDグループ２３１のストレージ装置内での識別子である。RAIDレベルＣ２３１は、RAIDグループ２３１のRAIDレベルである。RAIDレベルとしては、例えば、RAID１，RAID２，RAID３，RAID４，RAID５，RAID６などが知られている。容量Ｃ２３２は、RAIDグループ２３１の容量である。
　図１０には、RAIDグループ管理表Ｔ２３の具体的な値の一例が示されている。第１行目に着目すると、RAIDグループ２３１（RG1）は、RAIDレベルがRAID1であり、かつ、容量は100GBである。
　図１１は、イベント管理表Ｔ３０の構成例を示す図である。イベント管理表Ｔ３０は、管理サーバ３０の管理下にある各装置で発生したイベントを管理する。イベント管理表Ｔ３０は、例えば、イベントID　Ｃ３００と、装置ID　Ｃ３０１と、部位IDＣ３０２と、パラメータＣ３０３と、状態Ｃ３０４と、処理済みフラグＣ３０５と、日時Ｃ３０６の各フィールドを対応付けて管理する。
　イベントID　Ｃ３００は、イベントの識別子である。イベントの発生は、後述の通り、構成情報の変化に基づいて判断される。装置ID　Ｃ３０１は、イベントの発生した装置（機器）の識別子である。部位ID　Ｃ３０２は、装置内の、イベントの発生した部位を特定する識別子である。パラメータＣ３０３は、構成情報の変化を検知したパラメータの名称である。状態Ｃ３０４は、構成情報の変化の種別を示す。状態の種別としては、例えば、「変更」、「追加」、「削除」がある。処理済みフラグＣ３０５は、イベントが後述するイベント伝播モデル展開モジュールＰ３５によって処理済みかどうかを示す。日時Ｃ３０６は、イベントが発生した日時である。
　例えば、第１行目（１つ目のエントリ）に着目する。そこには、管理サーバ３０が、ストレージ装置２０（SYS1）のiSCSIターゲット（TG1）に接続可能なiSCSIイニシエータの変更をイベント（EV1）として検知したことが記録されている。
　図１２Ａ及び図１２Ｂは、イベント伝播モデルリポジトリＴ３１内のイベント伝播モデルの構成例を示す。イベント伝播モデルは、「所定の解析ルール」の一例である。一般的に、障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害（原因）の結果発生することが予想されるイベントの組み合わせと、その根本原因とを”IF-THEN”形式で記載する。
　本実施形態では、便宜上、図１２Ａ及び図１２Ｂに示すように、２つのイベント伝播モデルを説明する。その２つに限らず、更に多くのイベント伝播モデル（ルール）が用意されてもよい。イベント伝播モデルは、例えば、モデルID　Ｃ３１０と、観測事象Ｃ３１１と、原因Ｃ３１２の各フィールドを対応付けて管理する。
　モデルID　Ｃ３１０は、イベント伝播モデルの識別子である。観測事象Ｃ３１１は、ある原因の結果として観測される、複数の関連したイベントを示す。観測事象は、”IF-THEN”形式で記載したイベント伝播モデルのIF部に相当する。原因Ｃ３１２は、観測事象のうち原因となる事象である。原因事象（原因イベント）は、”IF-THEN”形式で記載したイベント伝播モデルのTHEN部に相当する。
　結論部である原因Ｃ３１２のイベントが正常になれば、条件部である観測事象Ｃ３１１の状態も正常に戻るという関係にある。
　図１２Ａには、イベント伝播モデルの具体的な値の一例が示されている。或るイベント伝播モデル（Rule1）では、ホストコンピュータ１０上の論理ボリュームのERRORと、ストレージ装置２０におけるI/Oポート２００のERRORとを検知したとき、ストレージ装置２０のI/Oポート２００の故障が原因であると結論付ける。
　図１３Ａ、図１３Ｂ、図１３Ｃ、及び図１３Ｄは、因果律行列Ｔ３２の構成を示す。因果律行列Ｔ３２は、計算機システムの各装置で生じる障害イベントの具体的な因果関係を規定する。因果律行列Ｔ３２は、例えば、イベント伝播モデルID　Ｃ３２０と、観測事象Ｃ３２１と、原因事象Ｃ３２２と、因果関係Ｃ３２３の各フィールドを対応付けて管理する。
　イベント伝播モデルID　Ｃ３２０は、展開処理に使用したイベント伝播モデルの識別子である。観測事象Ｃ３２１には、管理サーバ３０の状態取得モジュールＰ３２が管理対象の各装置から受信しうるイベント（障害イベント）が登録される。原因事象Ｃ３２２には、障害イベントを受信した際に、イベント解析処理部Ｐ３４が障害原因として結論付ける原因事象が登録される。因果関係Ｃ３２３には、どのイベントが受信された場合に、どのイベントを根本原因であると判断するかという対応関係が登録される。
　図１３Ａには、因果律行列Ｔ３２の具体的な値の一例が示されている。例えば、ストレージ装置２０（SYS1）のボリューム（VOL1）のERRORと、ホスト１０（HOST1）の論理ボリューム（E:）のERRORという２つのイベントが検知されると、ストレージ装置２０（SYS1）のボリューム（VOL1）の故障が根本原因であると判断される。
　図１４は、トポロジ生成方式リポジトリＴ３３内のトポロジ生成方式の構成例を示す。トポロジ生成方式とは、管理対象の各装置から取得した構成情報に基づいて、管理対象の各装置間での接続関係（トポロジ）を生成する方法を定義したものである。
　トポロジ生成方式は、例えば、トポロジID　Ｃ３３０と、起点コンポーネントＣ３３１と、終点コンポーネントＣ３３２と、経由コンポーネントＣ３３３と、トポロジ生成条件Ｃ３３４の各フィールドを対応付けて管理する。
　トポロジID　Ｃ３３０は、トポロジの識別子である。起点コンポーネントＣ３３１は、トポロジの起点となる、ノード装置内のコンポーネント種別である。終点コンポーネントＣ３３２は、トポロジの終点となる、ノード装置内のコンポーネント種別である。経由コンポーネントＣ３３３は、起点コンポーネントから終点コンポーネントまでの間のトポロジ生成の際に経由する、ノード装置内のコンポーネント種別である。トポロジ生成条件Ｃ３３４は、起点コンポーネントから終点コンポーネントまでの間のトポロジを生成する方法である。
　図１４Ａには、トポロジ生成方式Ｔ３３の具体的な値の一例が示されている。図１４Ａには、ホストコンピュータ１０の論理ボリュームを起点とし、ストレージ装置２０のI/Oポート２００を終点とし、かつ、ストレージ装置２０のiSCSIターゲットを経由するトポロジが記載されている。そのトポロジは、論理ボリュームのiSCSIイニシエータ名がiSCSIターゲットの接続許可iSCSIイニシエータと等しく、かつ、I/Oポート２００内のiSCSIターゲットIDがiSCSIターゲット内のIDと等しい組み合わせを検索することにより、取得可能である。
　図２２のフローチャートを参照して、構成情報を取得する処理を説明する。構成情報取得処理は、管理サーバ３０の構成情報取得モジュールＰ３１により実施される。以下、ステップを「Ｓ」と略記することがある。
　プログラム制御モジュールＰ３０は、所定のタイミングで、構成情報取得モジュールＰ３１に対して構成情報取得処理の実行を指示する。所定のタイミングとしては、例えば、プログラム制御モジュールＰ３０の起動時、または、前回の構成情報取得処理から一定時間経過後などを挙げることができる。なお、厳密に一定期間毎に指示が出される必要は無く、構成情報取得処理が繰り返し実行されていればよい。
　構成情報取得モジュールＰ３１は、管理対象の各装置に対し、以下のＳ６１－Ｓ６６を繰り返す（Ｓ６０）。まず最初に、構成情報取得モジュールＰ３１は、管理対象の装置に対し、構成情報を送信するよう指示する（Ｓ６１）。構成情報取得モジュールＰ３１は、管理対象装置からの応答があったか否かを判定する（Ｓ６２）。
　管理対象装置から構成情報が応答された場合（Ｓ６２：ＹＥＳ）、構成情報取得モジュールＰ３１は、取得した構成情報と構成データベースＴ３６に格納された過去の構成情報とを比較する（Ｓ６３）。管理対象装置から構成情報の応答がなかった場合（Ｓ６２：ＮＯ）、構成情報取得処理を終了する。
　構成情報取得モジュールＰ３１は、取得した構成情報と構成データベースＴ３６に格納された過去の構成情報とに差分があるか否かを判定する（Ｓ６４）。つまり、現在の構成情報と過去の構成情報とが異なるか否か判定する。
　現在の構成情報と過去の構成情報との間に差分がある場合（Ｓ６４：ＹＥＳ）、構成情報取得モジュールＰ３１は、差分のあった箇所をイベント化し、イベント管理表Ｔ３０に登録する（Ｓ６５）。イベント化するとは、差分の発生した構成をイベントとして取り扱うという意味である。
　構成情報取得モジュールＰ３１は、Ｓ６２で取得した構成情報（現在の構成情報）を、構成データベースＴ３６に格納する（Ｓ６６）。
　管理対象の全ての装置について上記の処理Ｓ６１－Ｓ６６が終了した後、構成情報取得モジュールＰ３１は、イベント伝播モデルの再展開をすべきか否かを確認するための処理を実行させる（Ｓ６７）。以上が、情報取得モジュールＰ３１が実施する構成情報取得処理である。
　図１５を参照して、本実施形態の特徴を備えない再展開要否確認処理を、本実施形態との相違を明らかにするために説明する。すなわち、図１５のフローチャートは、比較例である。
　再展開要否確認処理とは、イベント伝播モデルを展開して因果律行列を作成し直すか否か判断するための処理である。
　図１５に示す比較例の場合、イベント管理表Ｔ３０に、未処理のイベントがあるか否かが判定される（Ｓ１０）。
　未処理イベントがある場合（Ｓ１０：ＹＥＳ）、その未処理イベントの処理済みフラグＣ３０５の値は「ＹＥＳ」に変更される（Ｓ１１）。その後、図１６に示すイベント伝播モデルを再展開する処理が実行される（Ｓ１２）。
　このように、本実施形態の特徴を備えない比較例においては、計算機システムの構成が変更されるたびに、一律に、イベント伝播モデルを再展開する処理が実行される。従って、管理サーバ３０の処理負荷が増大する。
　図１６のフローチャートを参照して、本実施形態の特徴を備えないイベント伝播モデル再展開処理を説明する。つまり、図１６のフローチャートは、比較例である。
　最初に、因果律行列は全て削除される（Ｓ２０）。次に、イベント伝播モデルリポジトリに定義された全てのイベント伝播モデルに対し、以下の一連の処理Ｓ２３－Ｓ２４を繰り返す（Ｓ２１）。
　イベント伝播モデルに対応したトポロジ生成方式がトポロジ生成方式リポジトリから取得される（Ｓ２２）。対応するトポロジ生成方式が取得できると（Ｓ２３：ＹＥＳ）、そのトポロジ生成方式に基づいて構成データベースからトポロジが取得される（Ｓ２４）。さらに、その取得されたトポロジにイベント伝播モデルを展開して、因果律行列に追加する（Ｓ２４）。
　例えば、図１２Ａに示すイベント伝播モデル（Rule1）は、観測事象として”ホストコンピュータの論理ボリュームのERROR”と、”ストレージ装置のI/OポートのERROR”とが定義されている。
　図１４Ａに示すトポロジ生成方式を参照する。図１４Ａには、ホストコンピュータの論理ボリュームを起点コンポーネントとし、ストレージ装置のI/Oポートを終点コンポーネントとする、トポロジ生成方式（TP1）が定義されている。そこで、このトポロジ生成方式（TP1）を利用して、トポロジを取得する。
　図６Ａに示す論理ボリューム管理表Ｔ１０を参照し、ホストコンピュータ１０（HOST1）の論理ボリューム（E:）に着目する。論理ボリューム（E:）のiSCSIイニシエータ名は”com.abc.sv1”となっている。
　次に、図８に示すiSCSIターゲット管理表Ｔ２１を参照し、接続先iSCSIイニシエータ名が”com.abc.sv1”となっているiSCSIターゲットTG1を検索する。図９に示すI/Oポート管理表Ｔ２２を参照し、iSCSIターゲットIDがTG1となっているI/Oポート２００（PORT1）を検索する。
　以上の処理を行った結果、ホストコンピュータの論理ボリュームとストレージ装置のI/Oポートを含むトポロジの一つとして、ホストコンピュータ１０（HOST1）の論理ボリューム（E:）と、ストレージ装置２０（SYS1）のI/Oポート２００（PORT1）の組み合わせが検出される。
　そこで、新たな因果律行列が作成される。その因果律行列は、観測事象として”ホストコンピュータ１０（HOST1）の論理ボリューム（E:）のERROR”と”ストレージ装置２０（SYS1）のI/Oポート２００（PORT1）のERROR”とが検知された場合、”ストレージ装置２０（SYS1）のI/Oポート２００（PORT1）の故障”が原因であるとする。
　上記の処理Ｓ２２－Ｓ２４を、論理ボリューム管理表Ｔ１０に定義された、ホストコンピュータ１０の論理ボリューム全てを起点コンポーネントとして実行する。以上が、比較例としてのイベント伝播モデル再展開処理である。
　このように、比較例では、管理対象装置の構成変化を検知する度に、イベント伝播モデルを再展開する。従って、大規模なデータセンタ等のように、管理サーバ３０が管理する装置が多い場合、多数の構成変化が発生し、さらに、管理対象装置を管理するためのデータ量も増大する。この結果、イベント伝播モデルを再展開する処理が比較的頻繁に実行され、管理サーバ３０に生じる処理負荷が増大する。
　そこで、本実施形態では、再展開要否確認処理とイベント伝播モデル再展開処理を、独自の思想に基づいて改善する。
　本実施形態に特有の展開対象イベント管理表Ｔ３４を図１７に示す。さらに、本実施形態に特有の展開対象イベント伝播モデル管理表Ｔ３５を図１８に示す。さらに、本実施形態による管理サーバ３０の動作を図１９及び図２０に示す。
　展開対象イベント管理表Ｔ３４は、管理者が手動で定義してもよいし、後述する第２実施例に示す方法により自動的に生成してもよい。
　図１７は、「対象イベント管理情報」の一例としての展開対象イベント管理表Ｔ３４の構成例を示す。展開対象イベント管理表Ｔ３４は、イベント伝播モデルを展開する必要のあるイベントを管理する。展開対象イベント管理表Ｔ３４は、例えば、機器種別Ｃ３４０と、コンポーネント種別Ｃ３４１と、パラメータＣ３４２と、イベント種別Ｃ３４３と、イベント伝播モデルID　Ｃ３４４の各フィールドを対応付けて管理する。
　機器種別Ｃ３４０は、構成変化イベントの発生した装置の種別である。コンポーネント種別Ｃ３４１は、構成変化イベントの発生した装置内のコンポーネントの種別である。パラメータＣ３４２は、構成情報の変化が検知されたパラメータの名称である。イベント種別Ｃ３４３は、構成情報の変化の種別である。構成情報の変化には、例えば、「追加」、「削除」、「変更」がある。それらの構成変化（追加、削除、変更）に係るイベントを、ここでは構成変化イベントと呼ぶ。イベント伝播モデルID　Ｃ３４４は、構成変化イベントに適用すべきイベント伝播モデルの識別子である。
　図１７には、展開対象イベント管理表Ｔ３４の具体的な値の一例が示されている。例えば、ストレージ装置のiSCSIターゲットへの接続が許可されたiSCSIイニシエータの値が変更にされた場合、その構成変化イベントについて、イベント伝播モデル（Rule1）が再展開される。展開対象イベント管理表Ｔ３４に記載されていないイベントが発生した場合、イベント伝播モデルの再展開は行われない。
　図１８は、展開対象イベント伝播モデル管理表Ｔ３５の構成例を示す。展開対象イベント管理表Ｔ３５は、展開対象となるイベント伝播モデルを定義する。展開対象イベント伝播モデル管理表Ｔ３５は、どのイベント伝播モデルが展開対象となるかを登録するフィールドを持つ。
　図１８には、具体的な一例が示されている。或る一つのイベント伝播モデル（Rule1）と他の一つのイベント伝播モデル（Rule2）とが再展開の対象になっている。
　図１９に、構成情報取得モジュールＰ３１が実施する、再展開要否確認処理のフローチャートを示す。
　構成情報取得モジュールＰ３１は、イベント管理表Ｔ３０を参照し、未処理イベントがあるかどうかを確認する（Ｓ３０）。未処理イベントとは、構成変化を示すイベントであって、処理済みフラグＣ３０５に「ＮＯ」と設定されているイベントである。
　未処理イベントがある場合（Ｓ３０：ＹＥＳ）、構成情報取得モジュールＰ３１は、その未処理イベントについて、ループ内の処理Ｓ３２－Ｓ３４を繰り返す（Ｓ３１）。
　構成情報取得モジュールＰ３１は、未処理イベントと同種のイベントが展開対象イベント管理表Ｔ３４に登録されているかどうかを確認する（Ｓ３２）。
　展開対象イベント管理表Ｔ３４に未処理イベントと同種のイベントが存在する場合（Ｓ３２：ＹＥＳ）、構成情報取得モジュールＰ３１は、展開対象イベント管理表Ｔ３４に定義された展開が必要なルールを、展開対象イベント伝播モデル管理表Ｔ３５に登録する（Ｓ３３）。最後に、構成情報取得モジュールＰ３１は、未処理イベントの処理済みフラグＣ３０５を「ＹＥＳ」に変更する（Ｓ３４）。
　以上の処理が終了した後、構成情報取得モジュールＰ３１は、イベント伝播モデル展開モジュールＰ３５に対して、図２０に示すイベント伝播モデル再展開処理を行なうよう指示する。以上が、本実施形態による再展開要否確認処理である。本実施形態では、構成変化を示すイベントのうち展開対象イベント管理表Ｔ３４に登録されているイベントについてのみ、イベント伝播モデル再展開処理の対象とする。従って、管理サーバ３０の負担を軽減できる。
　図２０に、イベント伝播モデル展開モジュールＰ３５が実施するイベント伝播モデル再展開処理のフローチャートを示す。
　イベント伝播モデル展開モジュールＰ３５は、展開対象イベント伝播モデル管理表Ｔ３５に定義された全てのイベント伝播モデルに対し、以下の一連の処理Ｓ４１－Ｓ４４を繰り返す（Ｓ４０）。なお、展開対象イベント伝播モデル管理表Ｔ３５にIDが一つも登録されていない場合は、以下の処理Ｓ４１－Ｓ４４を行わずに、本処理を終了する。
　以下、処理対象のイベント伝播モデルを対象イベント伝播モデルと称する。イベント伝播モデル展開モジュールＰ３５は、対象イベント伝播モデルのIDを持つ因果律行列Ｔ３２を全て削除する（Ｓ４１）。イベント伝播モデル展開モジュールＰ３５は、トポロジ生成方式リポジトリＴ３３を参照し、対象イベント伝播モデルに対応したトポロジ生成方式を、トポロジ生成方式リポジトリＴ３３から取得する（Ｓ４２）。
　対応するトポロジ生成方式がある場合（Ｓ４３：ＹＥＳ）、イベント伝播展開モジュールＰ３５は、そのトポロジ生成方式に基づいて構成データベースＴ３６からトポロジを取得する。イベント伝播展開モジュールＰ３５は、そのトポロジにイベント伝播モデルを適用し、因果律行列Ｔ３２の列として追加する（Ｓ４４）。
　イベント伝播展開モジュールＰ３５は、展開対象イベント伝播モデル管理表Ｔ３５に定義された全てのイベント伝播モデルに対して上記処理Ｓ４１－Ｓ４４が終了した後、展開対象イベント伝播モデル管理表Ｔ３５に定義されたIDを全て削除する（Ｓ４５）。以上が、イベント伝播モデル再展開処理である。
　以下、構成情報取得処理の具体例を示す。処理開始当初の、イベント伝播モデルＴ３１（Rule1）に関する因果律行列Ｔ３２は図１３Ａに、イベント伝播モデルＴ３１（Rule2）に関する因果律行列Ｔ３２は図１３Ｃに、RAIDグループ管理表Ｔ２３は図１０に、iSCSIターゲット管理表Ｔ２１は図８Ａに、それぞれ示す通りであるものとする。
　プログラム制御モジュールＰ３０は、管理者からの指示もしくはタイマーによるスケジュール設定に応じて、構成情報取得モジュールＰ３１に対し、構成情報取得処理を実行するよう指示する。構成情報取得モジュールＰ３５は、管理下の各装置に順番にログインし、装置の種別に応じた構成情報を送信するよう指示する。
　上記の処理が終了した後、構成情報取得モジュールＰ３５は、構成データベースＴ３６に格納された過去の構成情報と、管理対象の各装置から取得した現在の構成情報とを比較し、イベント管理表Ｔ３０を更新する。
　ここでは、図１１のイベント管理表Ｔ３０の１行目に示す通り、ストレージ装置２０（SYS1）のiSCSIターゲット（TG1）に接続を許可されたiSCSIイニシエータが変更されたケースを想定する。なお、変更後のiSCSIターゲット管理表Ｔ２１を図８Ｂに示す。
　構成情報取得モジュールＰ３１は、イベント管理表Ｔ３０に定義されたイベントに対して、以下の処理を行う。まず最初に、構成情報取得モジュールＰ３１は、展開対象イベント管理表Ｔ３４を参照し、イベント管理表Ｔ３０に登録されたイベントと同種のイベントが定義されているかどうかを確認する。
　ここでいう同種とは、装置種別、装置内のコンポーネント種別、パラメータの名称、状態変化の種別の全てが等しいことを表す。展開対象イベント管理表Ｔ３４に同種イベントが存在する場合、構成情報取得モジュールＰ３１は、展開対象イベント管理表Ｔ３４のイベント伝播モデルID　Ｃ３４４に定義されたルール（イベント伝播モデル）を、展開対象イベント伝播モデル管理表Ｔ３５に登録する。
　例えば、図１７に示す展開対象イベント管理表Ｔ３４には、再展開が必要なイベントの種別の一つとして、”ストレージ装置のiSCSIターゲットに接続が許可されたiSCSIイニシエータの変更”が定義されている。構成情報取得モジュールＰ３１は、そのイベント種別に対応するイベント伝播モデルのID（Rule1）を、展開対象イベント伝播モデル管理表Ｔ３５に登録する。
　上記の処理が終了した後、構成情報取得モジュールＰ３１は、イベント伝播モデル展開モジュールＰ３５に対し、イベント伝播モデル再展開処理を行なうよう指示する。イベント伝播モデル展開モジュールＰ３５は、展開対象イベント伝播モデル管理表Ｔ３５を参照し、展開対象イベント伝播モデル管理表Ｔ３５に登録されたRule1について、再展開処理を行う。
　すなわち、イベント伝播モデル展開モジュールＰ３５は、イベント伝播モデルIDがRule1となっている列を、因果律行列Ｔ３２から削除する。次に、イベント伝播展開モジュールＰ３５は、イベント伝播モデル（Rule1）を展開し、因果律行列Ｔ３２に追加する。展開の方法は、図２０で述べた方法と同じである。
　以上の処理により、イベント伝播モデル（Rule1）に関する因果律行列Ｔ３２が更新され、図１３Ａに示す状態から図１３Ｂに示す状態に変化する。
　次に、図１１のイベント管理表Ｔ３０の２行目に示す通り、ストレージ装置２０（SYS1）の、ボリューム２３２（VOL1）の属するRAIDグループ２３１のIDが変更されたケースを想定する。変更後のボリューム管理表Ｔ２０を図７Ｂに示す。
　イベント管理表Ｔ３０に定義された構成変化に係るイベントに対して、以下の処理が実行される。展開対象イベント管理表Ｔ３４が参照され、イベント管理表Ｔ３０に定義されたイベントと同種のイベントが管理表Ｔ３４に定義されているか否か確認される。
　展開対象イベント管理表Ｔ３４に同種イベントが定義されている場合、展開対象イベント管理表Ｔ３４のイベント伝播モデルID　Ｃ３４４に定義されたイベント伝播モデル（ルール）は、展開対象イベント伝播モデル管理表Ｔ３５に登録される。
　例えば、図１７に示す展開対象イベント管理表Ｔ３４には、再展開が必要なイベントの種別として、”ストレージ装置のボリュームに関するRAIDグループIDの変更”が定義されている。構成情報取得モジュールＰ３１は、そのイベント種別に対応するイベント伝播モデルIDであるRule2を、展開対象イベント伝播モデル管理表Ｔ３５に登録する。
　上記の処理が終了した後、構成情報取得モジュールＰ３１は、イベント伝播モデル展開モジュールＰ３５に対し、イベント伝播モデル再展開処理を行なうよう指示する。イベント伝播モデル展開モジュールＰ３５は、展開対象イベント伝播モデル管理表Ｔ３５を参照し、展開対象イベント伝播モデル管理表Ｔ３５に登録されたRule2について、再展開処理を行う。
　すなわち、イベント伝播モデルIDがRule2となっている列は、因果律行列Ｔ３２から削除される。次に、イベント伝播モデル（Rule2）が展開され、因果律行列Ｔ３２に追加される。展開の方法は、図２０で述べた方法と同じである。
　以上の処理により、イベント伝播モデル（Rule2）に関する因果律行列Ｔ３２が更新され、図１３Ｃに示す状態から図１３Ｄに示す状態に変化する。
　ところで、図１１のイベント管理表Ｔ３０の３行目に示す通り、ストレージ装置２０（SYS1）のボリューム２３２（VOL5）の容量が変更されたケースを想定する。容量変更イベントと同種のイベントは、展開対象イベント管理表Ｔ３４に定義されていない。従って、構成情報取得モジュールＰ３１は、イベント伝播モデル展開モジュールＰ３５に対して、イベント伝播モデル再展開処理を指示しない。そのため、因果律行列Ｔ３２は更新されない。
　本実施形態によれば、管理対象の装置に関する構成変更イベントが検知された場合に、構成変更イベント毎に再展開が必要なイベント伝播モデルを特定し、再展開が必要なイベント伝播モデルについてのみ展開を行なう。従って、本実施形態では、無駄な再展開処理を抑制して、管理サーバ３０の処理負荷を軽減することができる。
　図２１及び図２３を参照して第２実施例を説明する。本実施例は、第１実施例の変形例に該当する。従って、第１実施例との相違を中心に説明する。
　本実施形態では、イベント伝播モデル展開モジュールＰ３５が実施する、展開対象イベント管理表生成処理方法について説明する。
　図２１のフローチャートに示すように、本実施形態では、イベント伝播モデル展開モジュールＰ３５は、展開対象イベント管理表Ｔ３４を自動的に生成する。以下、便宜上、展開モジュールＰ３５と呼ぶことがある。
　展開対象イベント管理表Ｔ３４を生成する処理は、所定のタイミングで実行できる。所定のタイミングとしては、例えば、管理サーバ３０が初めて起動した場合、イベント伝播モデルリポジトリＴ３１に新しいイベント伝播モデルが追加された場合、イベント伝播モデルリポジトリＴ３１のイベント伝播モデルの一部が削除された場合などを挙げることができる。
　展開モジュールＰ３５は、イベント伝播モデルリポジトリＴ３１に定義された全てのイベント伝播モデルに対し、以下の一連の処理Ｓ５１－Ｓ５３を繰り返す（Ｓ５０）。
　展開モジュールＰ３５は、トポロジ生成方式リポジトリＴ３３を参照し、イベント伝播モデルリポジトリＴ３１を生成するためのトポロジ生成方式を取得する （Ｓ５１）。
　展開モジュールＰ３５は、トポロジ生成方式のうち、起点コンポーネント、終点コンポーネント、および経由コンポーネントに記載されたコンポーネントを全て抽出する（Ｓ５２）。さらに、展開モジュールＰ３５は、抽出した各コンポーネントとイベント伝播モデルIDとを、展開対象イベント伝播モデル管理表Ｔ３４に追加する（Ｓ５２）。その場合、展開モジュールＰ３５は、イベント種別を「追加、削除」に設定し、かつ、パラメータは指定しない。
　次に、展開モジュールＰ３５は、トポロジ生成条件に記載されたコンポーネントおよびパラメータを全て抽出する（Ｓ５３）。さらに、展開モジュールＰ３５は、それら各コンピュータ及び各パラメータを、イベント伝播モデルIDと一緒に、展開対象イベント伝播モデル管理表Ｔ３４に追加する（Ｓ５３）。その場合、展開モジュールＰ３５は、イベント種別を「変更」に設定する。
　展開対象イベント管理表生成処理の具体例を以下に示す。
　展開モジュールＰ３５は、イベント伝播モデルリポジトリＴ３１に定義されたイベント伝播モデルについて、トポロジ生成方式リポジトリＴ３３から、イベント伝播モデルの生成に利用するトポロジ生成方式を取得する。
　展開モジュールＰ３５は、トポロジ生成方式のうち、起点コンポーネント、終点コンポーネント、および経由コンポーネントに記載されたコンポーネントを全て抽出し、展開対象イベント伝播モデル管理表Ｔ３５に追加する。
　例えば、図１２Ａに示すように、イベント伝播モデル（Rule1）は、ホストコンピュータ１０の論理ボリュームと、ストレージ装置２０のI/Oポートとから構成される。従って、そのイベント伝播モデル（Rule1）についてのトポロジを取得するために、図１４Ａに示すトポロジ生成方式（TP1）が用いられる。
　トポロジ生成方式（TP1）において、起点コンポーネントはホストコンピュータ１０の論理ボリュームであり、終点コンポーネントはストレージ装置２０のI/Oポートであり、経由コンポーネントはストレージ装置２０のiSCSIターゲットである。従って、図１７に示すように、それぞれのコンポーネントを展開対象イベント管理表Ｔ３４に追加する。その際、イベント種別Ｃ３４３の値には、「追加、削除」が設定される。適用ルールID（イベント伝播モデルID）Ｃ３４４の値には、「Rule1」が設定される。
　展開モジュールＰ３５は、トポロジ生成方式のトポロジ生成条件Ｃ３３４に記載されたコンポーネントおよびパラメータを全て抽出し、展開対象イベント伝播モデル管理表Ｔ３４に追加する。
　トポロジ生成方式（TP1）のトポロジ生成条件Ｃ３３４に記載されたコンポーネントおよびパラメータは、論理ボリュームのiSCSIイニシエータ名と、iSCSIターゲットに接続を許可されたiSCSIイニシエータと、I/Oポート２００のiSCSIターゲットIDと、iSCSIターゲットのIDである。従って、展開モジュールＰ３５は、それらを展開対象イベント管理表Ｔ３４に追加する。その際、イベント種別Ｃ３４３は「変更」に設定され、適用ルールID（イベント伝播モデルID　Ｃ３４４）はRule1に設定される。以上の処理により、展開対象イベント管理表Ｔ３４が生成されて、図１７に示す状態となる。
 
　本実施形態も第１実施形態と同様の効果を奏する。さらに、本実施形態では、イベント伝播モデルリポジトリＴ３１に登録されたイベント伝播モデルに基づいて、展開対象イベント管理表Ｔ３４を生成することができる。
　本実施形態では、例えば、管理者がイベント伝播モデルを追加もしくは削除した場合、展開対象イベント管理表Ｔ３４を自動的に更新することができる。従って、管理サーバ３０にかかる処理負荷を軽減しつつ、適切に因果律行列を生成できる。さらに、展開対象イベント管理表Ｔ３４を自動的に生成できるため、管理者の手間を省くことができる。
　図２３は、本実施形態の処理及び管理情報の関係を模式的に示す全体概念図である。管理サーバ３０は、展開対象イベント管理表生成処理（図２１）において、イベント伝播モデルＴ３１とトポロジ生成方式Ｔ３３とを参照し、展開対象イベント管理表Ｔ３４を生成する。展開対象イベント管理表Ｔ３４は、図１７で説明した通り、構成変更の結果であるイベントと、イベントが発生した場合に再展開すべきイベント伝播モデルとの対応関係を管理する。
　一方、管理サーバ３０は、再展開要否確認処理（図１９）において、イベント管理表Ｔ３０を参照し、未処理イベントの有無を確認する。管理サーバ３０は、未処理イベントがある場合、展開対象イベント管理表Ｔ３４を参照して、その未処理イベントについて再展開が必要なイベント伝播モデルを特定する。管理サーバ３０は、特定されたイベント伝播モデルについてのみ、イベント伝播モデル再展開処理を実行する。
　なお、第１実施形態及び第２実施形態は、以下のように、コンピュータプログラムとして表現することもできる。
　「コンピュータを、複数のノード装置を含む計算機システムを管理するための管理装置として機能させるためのコンピュータプログラムであって、
　前記コンピュータの備える記憶装置に、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とを格納し、
　前記所定の解析ルールは、障害の発生原因となる原因イベントと、前記原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義しており、
　　前記各ノード装置を監視する機能と、
　　前記各ノード装置の構成変化をイベントとして検知した場合、そのイベントが前記対象イベント管理情報に登録されているか否かを判定する機能と、
　　検知された前記イベントが前記対象イベント管理情報に登録されている場合に、所定の処理を実行させる機能とを、
前記コンピュータに実現させるためのコンピュータプログラム。」
　１０：ホストコンピュータ、２０：ストレージ装置、３０：管理サーバ、６０：通信ネットワーク

Claims (11)

  1. 　計算機システムを管理する方法であって、
    　前記計算機システムは、複数のノード装置と、前記複数のノード装置を管理するための管理装置とを含んでおり、
    　前記管理装置は、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とを保持しており、
    　前記所定の解析ルールは、障害の発生原因となる原因イベントと、前記原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義しており、
    　前記管理装置は、
    　　前記各ノード装置の構成変化をイベントとして検知した場合、そのイベントが前記対象イベント管理情報に登録されているか否かを判定し、
    　　検知された前記イベントが前記対象イベント管理情報に登録されている場合に、所定の処理を実行する、
    計算機システムの管理方法。
     
  2. 　前記管理装置は、前記複数のノード装置から構成情報を取得し、
    　前記所定の処理は、検知された前記イベントと前記対象イベント管理情報に基づいて処理すべき前記解析ルールを特定し、特定された前記解析ルールを前記構成情報に適用して、障害解析のための情報を生成する処理である、
    請求項１に記載の計算機システムの管理方法。
     
  3. 　前記管理装置は、前記所定の解析ルールの内容に基づいて、前記対象イベント管理情報を作成して保持する、
    請求項２に記載の計算機システムの管理方法。
     
  4. 　前記管理装置は、
    　　前記各ノード装置間の接続関係を示すトポロジを生成するためのトポロジ生成方法を複数記憶するトポロジ生成情報を保持しており、
    　　前記所定の解析ルールに対応する所定のトポロジ生成方法を前記トポロジ生成情報から取得し、
    　　取得された前記所定のトポロジ生成方法に規定されているノード装置を、イベントの発生元として前記対象イベント管理情報に登録することにより、前記対象イベント管理情報を作成して保持する、
    請求項３に記載の計算機システムの管理方法。
     
  5. 　前記管理装置は、
    　　所定のタイミングで、前記対象イベント管理情報を作成して保持するようになっており、
    　　前記所定のタイミングとは、前記管理装置が初めて起動した場合、または、新しい前記所定の解析ルールが追加された場合、または、既存の前記所定の解析ルールが削除または変更された場合、の少なくともいずれか一つの場合である、
    請求項４に記載の計算機システムの管理方法。
     
  6. 　前記各ノード装置のいずれかにおいて障害が検出された場合、前記障害解析のための情報に基づいて、検出された前記障害の原因を推定する、
    請求項５に記載の計算機システムの管理方法。
     
  7. 　複数のノード装置を含む計算機システムを管理するための管理装置であって、
    　マイクロプロセッサと、前記マイクロプロセッサにより実行される所定のコンピュータプログラム及び所定の情報を記憶する記憶装置と、前記マイクロプロセッサが前記各ノード装置と通信するための通信ポートを備え、
    　前記記憶装置には、少なくとも一つの所定の解析ルールと、前記管理装置が検知しうるイベントと前記所定の解析ルールとの対応関係を管理する対象イベント管理情報とが格納されており、
    　前記所定の解析ルールは、障害の発生原因となる原因イベントと、前記原因イベントにより引き起こされる障害を示す関連イベントとの関係を定義しており、
    　前記マイクロプロセッサは、前記所定のコンピュータプログラムを実行することで、
    　　前記各ノード装置を監視し、
    　　前記各ノード装置の構成変化をイベントとして検知した場合、そのイベントが前記対象イベント管理情報に登録されているか否かを判定し、
    　　検知された前記イベントが前記対象イベント管理情報に登録されている場合に、所定の処理を実行する、
    計算機システムの管理装置。
     
  8. 　前記記憶装置には、前記複数のノード装置から取得した構成情報が格納され、
    　前記所定の処理は、検知された前記イベントと前記対象イベント管理情報に基づいて処理すべき前記解析ルールを特定し、特定された前記解析ルールを前記構成情報に適用して、障害解析のための情報を生成する処理である、
    請求項７に記載の計算機システムの管理装置。
     
  9. 　前記マイクロプロセッサは、前記所定の解析ルールの内容に基づいて、前記対象イベント管理情報を作成して保持する、
    請求項８に記載の計算機システムの管理装置。
     
  10. 　前記記憶装置には、さらに、前記各ノード装置間の接続関係を示すトポロジを生成するためのトポロジ生成方法を複数記憶するトポロジ生成情報が格納されており、
    　前記マイクロプロセッサは、
    　　前記所定の解析ルールに対応する所定のトポロジ生成方法を前記トポロジ生成情報から取得し、
    　　取得された前記所定のトポロジ生成方法に規定されているノード装置を、イベントの発生元として前記対象イベント管理情報に登録することにより、前記対象イベント管理情報を作成して保持する、
    請求項９に記載の計算機システムの管理装置。
     
  11. 　前記マイクロプロセッサは、
    　　所定のタイミングで、前記対象イベント管理情報を作成して保持するようになっており、
    　　前記所定のタイミングとは、前記管理装置が初めて起動した場合、または、新しい前記所定の解析ルールが追加された場合、または、既存の前記所定の解析ルールが削除または変更された場合、の少なくともいずれか一つの場合である、
    請求項１０に記載の計算機システムの管理装置。
PCT/JP2011/057592 2011-03-28 2011-03-28 計算機システムの管理方法及び管理装置 WO2012131868A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2013506894A JP5352027B2 (ja) 2011-03-28 2011-03-28 計算機システムの管理方法及び管理装置
PCT/JP2011/057592 WO2012131868A1 (ja) 2011-03-28 2011-03-28 計算機システムの管理方法及び管理装置
US13/143,493 US8583789B2 (en) 2011-03-28 2011-03-28 Computer system management method and management apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/057592 WO2012131868A1 (ja) 2011-03-28 2011-03-28 計算機システムの管理方法及び管理装置

Publications (1)

Publication Number Publication Date
WO2012131868A1 true WO2012131868A1 (ja) 2012-10-04

Family

ID=46928789

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/057592 WO2012131868A1 (ja) 2011-03-28 2011-03-28 計算機システムの管理方法及び管理装置

Country Status (3)

Country Link
US (1) US8583789B2 (ja)
JP (1) JP5352027B2 (ja)
WO (1) WO2012131868A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8713356B1 (en) 2011-09-02 2014-04-29 Emc Corporation Error detection and recovery tool for logical volume management in a data storage system
WO2014141460A1 (ja) * 2013-03-15 2014-09-18 株式会社日立製作所 管理システム

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9104572B1 (en) * 2013-02-11 2015-08-11 Amazon Technologies, Inc. Automated root cause analysis
US9935823B1 (en) * 2015-05-28 2018-04-03 Servicenow, Inc. Change to availability mapping
US10977154B2 (en) * 2018-08-03 2021-04-13 Dynatrace Llc Method and system for automatic real-time causality analysis of end user impacting system anomalies using causality rules and topological understanding of the system to effectively filter relevant monitoring data

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001125854A (ja) * 1999-10-28 2001-05-11 Fujitsu Ltd ネットワーク管理装置および記録媒体
JP2007087232A (ja) * 2005-09-26 2007-04-05 Hitachi Ltd システム構成変更によるポリシ修正を容易にするポリシ作成方法、及びポリシ管理方法
WO2010016239A1 (ja) * 2008-08-04 2010-02-11 日本電気株式会社 障害解析装置
WO2010122604A1 (ja) * 2009-04-23 2010-10-28 株式会社日立製作所 複数のノード装置を含んだ計算機システムでのイベントの発生原因を特定する計算機

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7107185B1 (en) * 1994-05-25 2006-09-12 Emc Corporation Apparatus and method for event correlation and problem reporting
JP4335157B2 (ja) * 2005-02-01 2009-09-30 富士通株式会社 ネットワーク構成管理装置、ネットワーク構成管理プログラム及びネットワーク構成管理方法
US8086905B2 (en) * 2008-05-27 2011-12-27 Hitachi, Ltd. Method of collecting information in system network
JP5237034B2 (ja) * 2008-09-30 2013-07-17 株式会社日立製作所 イベント情報取得外のｉｔ装置を対象とする根本原因解析方法、装置、プログラム。

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001125854A (ja) * 1999-10-28 2001-05-11 Fujitsu Ltd ネットワーク管理装置および記録媒体
JP2007087232A (ja) * 2005-09-26 2007-04-05 Hitachi Ltd システム構成変更によるポリシ修正を容易にするポリシ作成方法、及びポリシ管理方法
WO2010016239A1 (ja) * 2008-08-04 2010-02-11 日本電気株式会社 障害解析装置
WO2010122604A1 (ja) * 2009-04-23 2010-10-28 株式会社日立製作所 複数のノード装置を含んだ計算機システムでのイベントの発生原因を特定する計算機

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8713356B1 (en) 2011-09-02 2014-04-29 Emc Corporation Error detection and recovery tool for logical volume management in a data storage system
WO2014141460A1 (ja) * 2013-03-15 2014-09-18 株式会社日立製作所 管理システム
JP5946583B2 (ja) * 2013-03-15 2016-07-06 株式会社日立製作所 管理システム
US9628360B2 (en) 2013-03-15 2017-04-18 Hitachi, Ltd. Computer management system based on meta-rules

Also Published As

Publication number Publication date
US20120254406A1 (en) 2012-10-04
US8583789B2 (en) 2013-11-12
JPWO2012131868A1 (ja) 2014-07-24
JP5352027B2 (ja) 2013-11-27

Similar Documents

Publication Publication Date Title
US11099953B2 (en) Automatic data healing using a storage controller
US20100306486A1 (en) Policy-based application aware storage array snapshot backup and restore technique
JP5534024B2 (ja) ストレージ制御装置およびストレージ制御方法
US20060259594A1 (en) Progressive deployment and maintenance of applications on a set of peer nodes
CN108369489B (zh) 预测固态驱动器可靠性
US10229023B2 (en) Recovery of storage device in a redundant array of independent disk (RAID) or RAID-like array
US10146628B2 (en) Software backup and restoration procedures using application and file monitoring
JP5352027B2 (ja) 計算機システムの管理方法及び管理装置
US11507474B2 (en) System and method for a backup and recovery of application using containerized backups comprising application data and application dependency information
US8346735B1 (en) Controlling multi-step storage management operations
WO2015043155A1 (zh) 一种基于命令集的网元备份与恢复方法及装置
US9280453B1 (en) Method and system for test automation framework for backup and recovery applications
US11281550B2 (en) Disaster recovery specific configurations, management, and application
JP2007323657A (ja) 過渡状態情報を格納するための方法、システムおよびコンピュータ・プログラム
US11226746B2 (en) Automatic data healing by I/O
US9971532B2 (en) GUID partition table based hidden data store system
CN115114086A (zh) 基于磁盘阵列的阵列卷恢复方法、系统、设备及存储介质
JP2015095015A (ja) データ配置方法、データ配置プログラムおよび情報処理システム
CN114047976A (zh) 插件加载方法、装置、电子设备、存储介质
US20130110789A1 (en) Method of, and apparatus for, recovering data on a storage system
JP7031224B2 (ja) 情報処理装置及びプログラム
WO2024131366A1 (zh) 一种集群修复方法及装置
US20240103984A1 (en) Leveraging backup process metadata for data recovery optimization
CN116302696A (zh) 数据库系统的归档日志生成方法、存储介质及计算机设备
JP2021144567A (ja) 制御装置、制御システムおよびデータ復旧方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 13143493

Country of ref document: US

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

Ref document number: 11862800

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013506894

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11862800

Country of ref document: EP

Kind code of ref document: A1