分析根本原因的管理计算机及方法

分析根本原因的管理计算机及方法
【专利摘要】对需要大规模或大量的事件传播模型的复杂计算机系统进行分析时的因果律矩阵的规模很大，大量消耗管理计算机的存储资源。为了解决以上问题，管理计算机系统的管理计算机将拓扑、事件传播模型和包含一个以上因果律的因果律信息保存在存储资源中，管理计算机以分析或检测到事件的契机，判断与分析对象事件对应的预定的因果律是否已生成，在未生成的情况下基于拓扑和事件传播模型来生成所述预定的因果律。
【专利说明】分析根本原因的管理计算机及方法
【技术领域】
[0001]本发明涉及计算机系统管理的程序。
【背景技术】
[0002]在专利文献I中公开了对在计算机系统的管理对象组件中发生的问题的原因进行确定的管理服务器。更具体而言，专利文献I的管理程序将管理对象装置中的各种故障事件化，将信息存储在事件数据库(DB)中。另外，该管理程序具有用于对在管理对象装置中发生的多个故障事件的因果关系进行分析的分析引擎。
[0003]分析引擎访问具有管理对象装置的目录信息的结构DB，将位于I/O系统路径上的总线上的管理对象装置内的组件视为I个组。此外，将管理对象装置内或跨管理对象装置的多个该装置或装置内的组件间的关系称为拓扑。而且，该分析引擎对所述拓扑应用由事先确定的条件句和分析结果构成的故障传播模型(IF-THEN形式规则)来构筑因果律矩阵。
[0004]在因果律矩阵中包含其他装置中的故障的原因的原因事件和由此引起的关联事件组。具体而言，故障传播模型的THEN部中作为故障的根本原因而记载的事件为原因事件，IF部所记载的事件中原因事件以外的事件为关联事件。
[0005]现有技术文献
[0006]专利文献
[0007]美国专利7107185号公报

【发明内容】

[0008]在专利文献I公开的技术中，基于管理对象的全部装置和全部故障传播模型，在事件分析前生成因果律矩阵。因此，对需要大规模或大量的故障传播模型的复杂计算机系统进行分析时的因果律矩阵的规模很大，会大量消耗管理计算机的存储资源(例如，存储器或/及辅助存储装置)。
[0009]为了解决以上的问题，管理计算机系统的管理计算机将拓扑、事件传播模型和包含一个以上因果律的因果律信息保存在存储资源中，管理计算机以分析或检测到事件为契机，判断是否已生成与分析对象事件对应的预定的因果律，在未生成的情况下基于拓扑和事件传播模型来生成所述预定的因果律。此外，因果律信息的一例为上述因果律矩阵。
[0010]发明的效果
[0011]根据上述手段，能够以更少的管理计算机的存储资源对需要更大规模或更大量的故障传播模型的复杂计算机系统进行分析。
【专利附图】

【附图说明】
[0012]图1是表示计算机系统的物理结构例的图。
[0013]图2是表示主计算机的详细结构例的图。
[0014]图3是表示存储装置的详细结构例的图。[0015]图4是表示管理服务器的详细结构例的图。
[0016]图5是表示IP交换机的详细结构例的图。
[0017]图6A是表示主计算机包含的逻辑卷管理表的构成例的图。
[0018]图6B是表示主计算机包含的逻辑卷管理表的构成例的图。
[0019]图6C是表示主计算机包含的逻辑卷管理表的构成例的图。
[0020]图7是表示存储装置包含的卷管理表的构成例的图。
[0021]图8A是表示存储装置包含的iSCSI目标器管理表的构成例的图。
[0022]图8B是表示存储装置包含的iSCSI目标器管理表的构成例的图。
[0023]图9是表示存储装置包含的I/O端口管理表的构成例的图。
[0024]图10是表示存储装置包含的RAID组管理表的构成例的图。
[0025]图11是表示存储装置包含的盘管理表的构成例的图。
[0026]图12是表示管理服务器包含的事件管理表的构成例的图。
[0027]图13A是表示管理服务器包含的事件传播模型的构成例的图。
[0028]图13B是表示管理服务器包含的事件传播模型的构成例的图。
[0029]图14A是表示管理服务器包含的因果律矩阵的构成例的图。
[0030]图14B是表示管理服务器包含的因果律矩阵的构成例的图。
[0031]图14C是表示管理服务器包含的因果律矩阵的构成例的图。
[0032]图14D是表示管理服务器包含的因果律矩阵的构成例的图。
[0033]图14E是表示管理服务器包含的因果律矩阵的构成例的图。
[0034]图15A是表不管理服务器包含的拓扑生成方式的构成例的图。
[0035]图15B是表示管理服务器包含的拓扑生成方式的构成例的图。
[0036]图16是表示管理服务器执行的装置信息获取处理的整体流程例的流程图。
[0037]图17是表示管理程序的逻辑构成例的图。
[0038]图18是表示管理服务器包含的展开对象事件传播模型管理表的构成例的图。
[0039]图19是表示管理服务器执行的事件确认处理的整体流程例的流程图。
[0040]图20是表示管理服务器执行的事件传播模型按需展开处理的整体流程例的流程图。
[0041]图21是表示管理服务器执行的事件传播模型再展开处理的整体流程例的流程图。
[0042]图22是表示管理服务器包含的已展开事件管理表的构成例的图。
[0043]图23是表示管理服务器包含的已展开起点组件管理表的构成例的图。
[0044]图24A是表示在实施例2中管理服务器执行的事件传播模型按需展开处理的整体流程例的流程图。
[0045]图24B是表示在实施例2中管理服务器执行的事件传播模型按需展开处理的整体流程例的流程图。
[0046]图25是表示在实施例3中管理服务器包含的事件传播模型管理表的构成例的图。
[0047]图26是表示在实施例3中管理服务器执行的事件传播模型按需展开处理的整体流程例的流程图。
[0048]图27是说明实施例的概要的示意图。[0049]图28是表示在实施例3中管理服务器执行的事件传播模型再展开处理的整体流程例的流程图。
[0050]图29是表示计算机系统的另一物理构成例的图。
【具体实施方式】
[0051]下面参照附图来说明实施例。此外，在以后的说明中通过“aaa表”、“aaa列表”、“aaaDB”、“aaa队列”、“aaa矩阵”等表现来说明实施例的信息，但这些信息也可以通过表、列表、DB、队列、矩阵等数据构造以外来表现。因此，为了表示不依赖数据构造而有时将“aaa表”、“aaa列表”、“aaaDB”、“aaa队列”、“aaa库”、“aaa矩阵”等称为“aaa信息”。进而，在说明各信息的内容时，使用“识别信息”、“标识符”、“名”、“姓名”、“ID”这样的表现，但它们能够相互替换。进而，为了表示数据内容而使用“信息”这样的表现，但也可以使用其他的表现形式。此外，在实施例的说明中使用了“库(r印ository)”这样的术语，具有与“信息”相同的意味。
[0052]在以后的说明中有时以“程序”作为主语进行说明，但由于使用存储器及通信端口(通信控制装置)进行通过由处理器执行程序而确定的处理，因此以处理器作为主语进行说明也可以。另外，以程序作为主语表示的处理也可以是管理服务器或存储系统等计算机、信息处理装置进行的处理。另外，程序的一部分或全部可以通过专用硬件来实现。另外，各种程序可以通过将程序分发服务器(由存储各种程序的安装镜像的存储资源和实施分发处理的CPU构成)或存储介质安装到各计算机中。
[0053]图27是表示实施例1的概要的图。管理服务器30000是管理多个管理对象装置10000的计算机。作为管理对象装置的类别，例如有主计算机、IP交换机和/或路由器等网络装置、NAS和/或存储装置等。此外，将管理对象装置包含的设备等的逻辑或物理上的构成物称为组件。作为组件的例子，有端口、处理器、存储资源、存储设备、程序，虚拟机、在存储装置内部定义的逻辑卷、RAID组等。此外，在不区分管理对象装置和组件来处理的情况下称为管理目标。
[0054]管理服务器30000获取表示这些管理对象装置的结构信息、故障或性能的信息等的装置信息，基于所获取的装置信息来表示管理对象装置的管理信息(例如结构信息、有无发生故障、性能值等)。
[0055]此外，几个管理对象装置是某些网络服务(例如iSCS1、文件共享服务、DNS、其他Web服务)的服务器，另外其他几个管理对象装置作为客户端而利用这些服务器提供的网络服务。在该情况下，若在服务器的管理对象装置(服务器)中产生与服务提供有关的问题(例如管理目标的故障、性能故障等)，则在利用该服务的客户端管理对象装置(有时称为客户端装置)中也会产生与管理目标有关的问题。
[0056]此外，在以后的说明中将由管理服务器表示在管理目标中产生了的问题的信息称为事件。另外，所谓“事件的检测”意味着“对问题的发生进行检测，生成事件信息”。此外，“事件的发生”具有与“问题的产生”相同的意思。
[0057]管理服务器30000能够将在某管理对象装置中产生的问题的原因是其他的管理对象装置中产生的问题这一情况进行分析并显示。因此管理服务器30000保存以下的信息并用于分析。[0058]*结构信息。保存表示管理对象装置的结构(也称为目录)的信息。此外，在结构信息中包含管理对象装置所含有的组件、和/或组件彼此的对应关系这样的管理目标间的对应关系。另外，在结构信息中，关于客户端装置而包括用于接受网络服务的服务器装置(或服务器装置的组件)的识别信息。例如，如果后述的由iSCSI协议实现的卷提供是网络服务，则作为识别信息而指定iSCSI目标器名和LUN，并访问存储装置提供的卷。另外，若为Web,则作为识别信息而指定包含Web服务器名的URL，并访问Web网页。
[0059]此外，在结构信息中，关于服务器装置，也有时包含与成为访问源的客户端装置有关的识别信息。将这样的管理对象装置内或跨多个管理对象装置的多个管理目标间的关系称为拓扑。
[0060]* 一个以上的事件传播模型的信息(以后，简称为事件传播模型)。本信息包含一个以上的观测类别对和原因类别对。作为更详细的说明如下。
[0061]原因类别对:是管理目标的类别(有时称为管理目标原因类别)和事件的类别(事件原因类别)的对。事件原因类别是在由管理目标原因类别确定的类别的管理目标中有可能产生的事件的类别。
[0062]观测类别对:是管理目标的类别(有时称为管理目标观测类别)和事件的类别(事件观测类别)的对。事件观测类别是在由管理目标观测类别确定的类别的管理目标中有可能产生的事件的类别。观测类别对表示当发生了在原因类别对中由类别确定的事件的情况下相应地产生的事件的类别。
[0063]此外，在将某事件传播模型所包含的观测类别对的事件全部检测到的情况下，对应的原因类别对的事件产生是原因，这是较优选而非必须。
[0064]更具体而言，管理服务器30000的分析处理基于事件传播模型和拓扑在因果律信息中生成因果律，在此基础上进行事件的分析。此外，所谓因果律是表示在第I管理目标中产生了第I事件的情况下在第2管理目标中产生第2事件这一情况的信息。此外，优选的是，能够判断成第I事件为原因的条件是检测与第I事件关联的全部的第2事件。但这不是必须的。因果律信息只要能够表示上述内容，也可以是因果律矩阵的形式，或也可以是运用表示关系的指示字信息来表示第I事件与第2事件的关系的数据构造。
[0065]管理服务器30000按需生成因果律。即，管理服务器30000判断与检测到但未分析的预定事件对应的因果律是否已生成在因果律信息中，在未生成的情况下使用与预定事件有关的拓扑和与预定事件有关的事件传播模型来生成因果律，然后进行预定事件的分析。
[0066]作为事件分析的例子考虑如下。
[0067]*对成为所检测到的某事件I的原因的事件2进行特定。该特定处理能够通过参照因果律信息来进行。此外，管理服务器(或后述的管理系统)也可以在自身的显示设备上与事件I的信息一起显示因事件2而产生了该事件的意思的消息。
[0068]*求出以所检测到的某事件3为原因而产生(或有可能产生)的事件4。该特定处理能够通过参照因果律信息来进行。此外，管理服务器(或后述的管理系统)也可以在自身的显示设备上显示事件4因事件3的产生而产生(或有可能产生)的意思的消息。
[0069]管理服务器30000在检测到事件之后，判断与检测事件有关的预定的因果律是否已生成在因果律信息中，在没有生成的情况下，基于(I)将检测事件包含在观测类别对或原因类别对中的事件传播模型和(2)与产生检测事件的组件有关的拓扑，在因果律信息中生成预定的因果律(在稍后的说明中也称为因果律展开)。此外，将这样的以事件检测为契机的因果律的展开称为按需展开。通过按需展开，即使在以大规模的计算机系统或复杂的计算机系统为对象的事件分析中也能够进一步减小因果律信息的规模。
[0070]在管理服务器30000检测到管理对象装置的结构变更、添加或删除的情况下，有时更新、添加或删除某一个拓扑。管理服务器30000将基于被更新或删除的拓扑生成的因果律从因果律信息中删除。然后，对于与更新后的拓扑相关的因果律，通过按需展开来生成。此外，对于被添加的拓扑，通过上述的按需展开来生成因果律。
[0071]在从开始分析起经过长时间后，存在从各种管理目标中检测各种类别的事件的倾向。在该情况下，因果律信息的大小由于按需展开而变大。因此，管理服务器30000可以对事件赋予有效期间，将有效期间期满的事件排除在分析对象之外，然后将与有效期间期满的事件有关的因果律从因果律信息中删除。如此一来，能够减小因果律信息的大小。
[0072]在图27的例子中，示出了在事件关联I已生成的状况下在组件3(类别a)中实际检测到事件A3 (类别A)时的概要，所述事件关联I表示组件I (类别a)中产生的事件Al (类别A)的原因是组件2 (类别b)中产生的事件B2(类别B)。此外，事件关联I是以过去检测到事件Al时为契机基于拓扑I和事件传播模型I在过去按需生成的。在该状况下，基于拓扑2和事件传播模型I按需生成事件关联2，所述事件关联2表示组件3 (类别a)中产生的事件A3 (类别A)的原因是组件2 (类别b)中产生的事件B2(类别B)。
[0073]此外，作为上述因果律的删除契机例如如下，但也可以是其他的契机。
[0074]*管理程序检测到管理对象装置的结构变更时。
[0075]*作为基于预定间隔的重复处理，执行删除。
[0076]此外，由于按需展开在事件分析时生成因果律，所以分析时的负荷增大。因此，对于特定的事件传播模型或特定的管理目标，也可以事先展开因果律。此外，将事先展开因果律的情况称为事先展开。作为事先展开的例子例如考虑(I)在管理程序起动并检测事件之前、或(2)在管理程序检测到管理对象装置的结构变更后且在检测最初的事件之前。但是，所谓事先，只要是在事件检测之前也可以是其他的定时(timing，时机)。作为成为事先展开对象的事件传播模型或管理目标的特定方法，考虑(I)将它们的标识符事先设定给用户的方法、(2)将管理目标的类别特定为条件、或(3)将事件传播模型所包含的管理目标的类别或事件类别特定为条件这样的例子，但也可以是其他方法。
[0077]在因果律已生成判断或因果律展开时，若访问各个事件传播模型来判断与事件的关系性，则会花费与模型数量成比例的时间。因此，管理服务器30000也可以根据管理目标的类别和在管理目标中产生的事件的类别的对，事先生成能够特定在原因类别对或观测类别对中包含该对的事件传播模型的ID的数据构造，并在判断中进行参照。
[0078]以上是本实施例的概要。在以后的记载中例示如下情况，但本发明当然不限定于此。
[0079]*网络服务:由iSCSI协议实现的存储访问。客户端装置为主计算机，服务器装置为存储装置。
[0080]*因果律信息:因果律矩阵。
[0081]*管理对象装置:主计算机、IP交换机、存储装置。
[0082]*管理目标:组件。[0083]*组件:iSCSI目标器、卷、RAID组、盘、主计算机的驱动器名。
[0084]*因果律的删除契机:结构变更的检测。
[0085]实施例1
[0086]图1?图5表示计算机系统的结构及与计算机系统连接的装置的结构，图6?图15表示各装置所具有的管理信息。
[0087]图1是表示计算机系统的物理结构的图。该计算机系统构成为，具有:存储装置20000、主计算机10000、管理服务器30000、WEB浏览器起动服务器35000和IP交换机40000，这些设备通过网络45000而连接。
[0088]主计算机10000至10010例如从其所连接的未图示的客户端计算机接收文件的I/O请求，基于该I/O请求实现向存储装置20000至20010的访问。另外，管理服务器(管理计算机)30000是对该计算机系统整体的运用进行管理的服务器。
[0089]WEB浏览器起动服务器35000是经由网络45000与管理服务器30000的⑶I显示处理模块32300进行通信并在WEB浏览器上显示各种信息的计算机。用户通过参照WEB浏览器起动服务器上的WEB浏览器所显示的信息，对计算机系统内的装置进行管理。但是，管理服务器30000和WEB浏览器起动服务器35000也可以由I台服务器构成。
[0090]另外，如图29所示，也可以在是，计算机系统上存在多台管理服务器30000，分担管理存储装置20000、主计算机10000、管理服务器30000等的管理对象装置。
[0091]图2是表示实施例的主计算机10000的详细内部结构例的图。主计算机10000具有用于与网络45000连接的端口 11000、处理器12000和存储器13000 (也可以包含盘装置)，它们成为经由内部总线等电路而相互连接的结构。
[0092]在存储器13000中保存有业务应用程序13100、操作系统13200和逻辑卷管理表13300。
[0093]业务应用程序13100使用从操作系统13200提供的存储区域，对该存储区域进行数据输入输出(以下记为I/o)。
[0094]操作系统13200执行用于使业务应用程序13100将经由网络45000与主计算机10000连接的存储装置20000至20010上的逻辑卷识别为存储区域的处理。
[0095]端口 11000在图2中表现为包含用于利用iSCSI与存储装置20000进行通信的I/O端口和用于供管理服务器30000获取主计算机内的管理信息的管理端口的单一端口，但也可以分开成用于利用iSCSI进行通信的I/O端口和管理端口。
[0096]图3是表示实施例的存储装置20000的详细的内部结构例的图。存储装置20010也具有同样的结构。
[0097]存储装置20000具有:用于经由网络45000与主计算机10000连接的I/O端口21000及21010、用于经由网络45000与管理服务器30000连接的管理端口 21100、用于保存各种管理信息的管理存储器23000、用于保存数据的RAID组24000至24010、和用于控制数据和/或管理存储器内的管理信息的控制器25000及25010，它们成为经由内部总线等电路而相互连接的结构。此外，RAID组24000至24010的连接，更正确而言是指构成RAID组24000至24010的存储设备与其他构成物连接。
[0098]在管理存储器23000中保存有存储装置的管理程序23100、卷管理表23200、iSCSI目标器管理表23300、I/O端口管理表23400、RAID组管理表23500和盘管理表23600。管理程序经由管理端口 21100与管理服务器30000通信，对管理服务器提供存储装置20000的结构信息。
[0099]RAID 组 24000 至 24010 分别由 I 个或多个磁盘 24200、24210、24220 以及 24230 构成。在由多个磁盘构成的情况下,这些磁盘也可以组成RAID结构。另外，RAID组24000至24010逻辑上被分割为多个卷24100至24110。
[0100]此外，逻辑卷24100及24110只要使用I个以上磁盘的存储区域而构成，则也可以不组成RAID结构。进而，只要提供与逻辑卷对应的存储区域，则也可以用闪存等使用了其他存储介质的存储设备来作为磁盘的替代品。
[0101]控制器25000及25010在其内部具有进行存储装置20000内的控制的处理器、和/或将在与主计算机10000之间授受的数据暂时存储的高速缓冲存储器。而且，各个控制器介于I/O端口与RAID组之间，在两者之间进行数据的交接。
[0102]此外，存储装置20000只要包含对任一个主计算机提供逻辑卷，接收访问请求(指I/o请求)，并根据所接收到的访问请求进行向存储设备的读写的存储控制器和提供存储区域的上述的存储设备，也可以是图3及上述说明以外的结构，例如也可以在另外的框体中收容存储控制器和提供存储区域的存储设备。即，在图3的例子中管理存储器23000、控制器25000及25110可以是存储控制器。另外，在本说明书中作为包括存储控制器和存储设备存在于同一框体中的情况或存在于不同框体的情况的表现，也可以将存储装置改称为存储系统。
[0103]图4及图17是表示实施例的管理服务器30000的详细的内部结构例的图。管理服务器30000具有用于与网络45000连接的管理端口 31000、处理器31100、存储资源33000、用于输出后述的处理结果的显示装置等输出设备31200、和用于供存储管理者输入指示的键盘等输入设备31300，它们成为经由内部总线等电路而相互连接的结构。此外，存储资源33000是半导体存储器、存储设备或同时具有半导体存储器和存储设备而成的存储资源。
[0104]在存储资源33000中保存有管理程序32000。如图17所示，管理程序32000包含程序控制模块32100、装置信息获取模块32200、⑶I显示处理模块32300、事件分析处理模块32400和事件传播模型展开模块32500。此外，各模块作为存储器32000的程序模块而提供，但也可以作为硬件模块而提供。另外，管理程序32000只要能够实现各模块的处理，则也可以不由模块来构成。换言之，关于以下说明的各模块的说明，也可以替换为与管理程序32000相关的说明。
[0105]存储资源33000还保存有事件管理表33100、事件传播模型库33200、因果律矩阵33300、拓扑生成方式库33400、结构DB33500、展开对象事件传播模型管理表33600、已展开事件管理表33700、已展开起点组件管理表33800和事件传播模型管理表33900。在结构DB33500中保存有结构信息。
[0106]作为结构信息的例子，是装置信息获取模块32200从管理对象的各主计算机收集来的逻辑卷管理表13300的各项目、从管理对象的各存储器收集来的卷管理表23200的各项目、iSCSI目标器管理表23300各项目、I/O端口管理表23400各项目、RAID组管理表23500各项目、和盘管理表23600各项目。此外，在结构DB中也可以不保存管理对象装置的全部表或表中的全部项目。另外，结构DB保存的各项目的数据表现形式、数据构造也可以不与管理对象装置相同。另外，在管理程序32000从管理对象装置接收这些各项目的情况下，也可以以管理对象装置的数据构造和/或数据表现形式来接收。
[0107]装置信息获取模块32200定期或重复访问管理下的管理对象装置，获取管理对象装置内的各组件的状态。事件分析处理模块32400参照因果律矩阵33300来分析装置信息获取模块32200所获取的管理对象装置的异常状态的根本原因。
[0108]⑶I显示处理模块33400根据经由输入设备31300来自管理者的请求，将所获取的结构管理信息经由输出设备31200进行显示。此外，输入设备和输出设备可以是分开的设备，也可以是一个以上的综合设备。
[0109]此外，管理服务器(管理计算机)例如作为输入输出设备而具有显示器、键盘和指示设备等，但也可以为此以外的装置。另外，也可以替代输入输出设备而使用串行接口和/或以太网接口，在该接口上连接具有显示器、键盘或指示设备的显示用计算机(例如WEB浏览器起动服务器35000)，通过将显示用信息发送给显示用计算机、从显示用计算机接收输入用信息，从而由显示用计算机进行显示、接受输入，由此代替通过输入输出设备进行的输入及显示。
[0110]在本说明书中，有时将管理计算机系统(信息处理系统)并显示显示用信息的一个以上的计算机的集合称为管理系统。在管理服务器显示显示用信息的情况下，管理服务器为管理系统，另外，管理服务器和显示用计算机(例如图1的WEB浏览器起动服务器35000)的组合也为管理系统。另外，为了管理处理的高速化和高可靠性，可以由多个计算机来实现与管理服务器同等的处理，在该情况下该多个计算机(在显示用计算机进行显示的情况下也包含显示用计算机)为管理系统。
[0111]图5中示出IP交换机40000的详细结构。IP交换机40000具有处理器41000、用于保持各种管理信息的存储器42000、用于经由网络45000、45010与主计算机10000连接的I/O端口 43000、43010、用于与网络45000连接的管理端口 44000，它们经由内部总线等电路而相互连接。
[0112]此外，对于存储器42000而言，其一部分或全部也可以为磁盘等其他存储介质来代替半导体存储器。
[0113]图6A、6B以及6C是表示主计算机10000具有的逻辑卷管理表13300的结构例的图。
[0114]逻辑卷管理表13300作为构成项目而包含:将在主计算机内成为各逻辑卷的标识符的驱动器名进行登记的字段13310、将与逻辑卷的实体所在的存储装置进行通信时使用的成为主计算机上的I/O端口 11000的标识符的iSCSI启动器名(initiator name)进行登记的字段13320、将与逻辑卷的实体所在的存储装置进行通信时使用的成为存储装置上的I/O端口 21000的标识符的连接目标iSCSI目标器进行登记的字段13330、将在存储装置中成为逻辑卷的标识符的LUN ID进行登记的字段13340。
[0115]图6A中示出了主计算机具有的逻辑卷管理表的具体值的一例。S卩，主计算机上由(E:)这一驱动器名所表示的逻辑卷经由由com.hitach1.svl这一 iSCSI启动器名所表示的主计算机上的端口和由com.hitach1.stol这一 iSCSI目标器名所表示的存储装置上的端口而与存储装置连接，在存储装置上持有O这一 LUN ID。
[0116]图7是表示存储装置20000具有的卷管理表23200的图。
[0117]卷管理表23200作为构成项目而包含:将在存储装置内成为各卷的标识符的卷ID进行登记的字段23210、将各卷的容量进行登记的字段23220、将成为各卷所属的RAID组的标识符的RAID组ID进行登记的字段23230、将成为各卷所属的iSCSI目标器的标识符的目标器ID进行登记的字段23240、和将成为各卷的iSCSI目标器内的标识符的LUN ID进行登记的字段23250。
[0118]图7中示出了存储装置具有的卷管理表的具体值的一例。即，存储装置上的卷VOLl具有20GB的存储区域，属于由RGl这一 RAID组ID所表示的RAID组，属于由TGl这一iSCSI目标器ID所表示的iSCSI目标器，持有O这一 LUN ID。
[0119]图8A及图8B是表示存储装置20000具有的iSCSI目标器管理表23300的图。
[0120]iSCSI目标器管理表23300作为构成项目而包含:将在存储装置内成为iSCSI目标器的标识符的目标器ID进行登记的字段23310、将各iSCSI目标器持有的iSCSI目标器名进行登记的字段23320、将被允许对属于各iSCSI目标器的卷进行访问的成为主计算机上的端口的标识符的iSCSI启动器名进行登记的字段23330。
[0121]图8A中示出了存储装置具有的iSCSI目标器管理表的具体值的一例。即，存储装置上的iSCSI目标器HGl持有com.hitach1.stol这一 iSCSI目标器名，允许从iSCSI启动器名为com.hitach1.svl或com.hitach1.svl I的主计算机上的端口进行的访问。
[0122]图9是表示存储装置20000具有的I/O端口管理表23400的构成的图。
[0123]I/O端口管理表23400作为构成项目而包含:将存储装置内成为各端口的标识符的端口 ID进行登记的字段23410、和用于将成为端口的网络45000上的标识符的MAC地址进行登记的字段23420。
[0124]图9中示出了存储装置具有的I/O端口管理表的具体值的一例。即，存储装置上的端口 PORTl被以TG1、TG2这样的iSCSI目标器ID所表示的iSCSI目标器使用。
[0125]图10是表示存储装置20000具有的RAID组管理表23500的构成的图。
[0126]RAID组管理表23500由字段23510、字段23520和字段23530构成，其中，字段23510中登记存储装置内成为各RAID组的标识符的RAID组ID，字段23520中登记RAID组的RAID级别，字段23530中登记各RAID组的容量。
[0127]图10中示出了存储装置具有的RAID组管理表的具体值的一例。即，存储装置上的RAID组RGl的RAID级别为RAID1，容量为100GB。
[0128]图11是表示存储装置20000具有的盘管理表23600的构成的图。
[0129]盘管理表23600由将存储装置内成为各盘的标识符的盘ID进行登记的字段23610和将盘的盘类别进行登记的字段23620构成。
[0130]图11中示出了存储装置具有的盘管理表的具体值的一例。即，存储装置上的盘DISKl的盘类别为FC盘。
[0131]图12是表示管理服务器30000具有的事件管理表33100的构成例的图。
[0132]事件管理表33100作为构成项目而包含:将成为事件本身的标识符的事件ID进行登记的字段33110、将成为发生了所获取的结构信息存在变化这一事件的装置的标识符的装置ID进行登记的字段33120、将事件产生的装置内的部位的标识符进行登记的字段33130、将所产生的事件的类别进行登记的字段33140、将事件是否已由后述的事件传播模型展开模块32500进行了处理进行登记的字段33150、将事件产生的日期和时间进行登记的字段33160、和将事件成为后述的事件传播模型展开模块32500的处理对象(或管理程序的原因分析对象)的期间进行登记的字段33170。
[0133]例如，从图12的第I行(第I条目)可知:管理服务器30000检测到主计算机HOSTl的由(E:)所表示的逻辑卷的状态异常，该事件ID为EVl。
[0134]图13A及图13B是表示管理服务器30000具有的事件传播模型库33200内的事件传播模型的构成例的图。故障分析中用于特定根本原因的事件传播模型是将预测到某故障的结果产生的事件的组合及其根本原因以“IF-THEN”形式来记载而得到的。此外，事件传播模型并不限于图13A及图13B所举例子，也可以为更多的规则。当然在事件传播模型库33200中也可以包含多个事件传播模型。
[0135]事件传播模型作为构成项目而包含:将成为事件传播模型的标识符的模型ID进行登记的字段33210、将与以“IF-THEN”形式记载的事件传播模型的IF部相当的观测事件类别进行登记的字段33220、用于将与以“IF-THEN”形式记载的事件传播模型的THEN部相当的原因事件类别进行登记的字段33230。具有若结论部的状态成为正常，则条件部的问题也已解决这一关系。
[0136]图13A中示出了管理服务器具有的事件传播模型的具体值的一例。即，在由模型ID为Rulel所表示的事件传播模型中，在作为观测事件类别而检测到主计算机上的逻辑卷的状态异常和存储装置上的卷的状态异常时，得到结论为存储装置的卷的故障是原因。
[0137]此外，如图13B所示，也可以具有作为观测事件为“存储装置的卷的故障”这样的在其他事件传播模型中作为结论进行定位的事件类别。
[0138]图14A至图14E是表示管理服务器30000具有的因果律矩阵33300的构成的图。
[0139]因果律矩阵33300包含以下的信息。
[0140]*将展开时使用的成为事件传播模型库33200的标识符的事件传播模型ID进行登记的字段33310。
[0141]*将用于对管理服务器的装置信息获取模块33300检测的事件进行特定的信息(图中为管理目标的标识符(即装置ID和组件ID)和事件的类别)进行登记的字段33320。
[0142]*在检测到所述事件时，对用于将结论为事件分析处理模块33500是故障的原因的原因事件进行登记的信息(图中为管理目标的标识符(即装置ID和组件ID)和事件的类别)进行登记的字段33330。
[0143]*用于将基于事件传播模型库33200中以“IF-THEN”形式记载的事件传播模型在接收到何种事件时将什么确定为根本原因这样的对应关系(即因果律)进行登记的字段33340。
[0144]图14A中示出了管理服务器具有的因果律矩阵的具体值的一例。即，在装置信息获取模块检测到存储装置SYSl的卷(VOLl)的状态异常和主机HOSTl的逻辑卷(E:)的状态异常这样的事件时，事件分析处理模块得到结论为存储装置SYSl的卷(VOLl)的故障是根本原因。
[0145]此外，为了如后述那样更有效地进行因果律的添加、删除，因果律矩阵也可以为能够变动地改变矩阵大小的数据构造。例如，考虑按每预定的行数或列数进行子矩阵化，以指针和/或索引使它们相关联而看作虚拟的矩阵等。另外，因果律矩阵也可以使用存储资源的连续区域来生成矩阵构造。
[0146]图15是表不管理服务器30000具有的拓扑生成方式库33400内的拓扑生成方式信息(有时省略而称为拓扑生成方式)的构成例的图。
[0147]拓扑生成方式是对用于基于所述管理服务器从管理对象装置获取的结构信息来生成成为监视对象的多个装置间的连接关系(拓扑)的手段进行定义的信息。拓扑生成方式作为构成项目而包含:将成为拓扑的标识符的拓扑ID进行登记的字段33410、将成为生成拓扑时的起点的管理对象装置内的组件类别进行登记的字段33420、将成为生成拓扑时的终点的组件类别进行登记的字段33430、将所述起点组件-终点组件间的拓扑生成时需要经由的组件类别进行登记的字段33440、和将所述起点组件-终点组件间的拓扑生成方法进行登记的字段33450。
[0148]图15中示出了管理服务器具有的拓扑生成方式的具体值的一例。即，以存储装置的卷为起点、以主计算机的逻辑卷为终点的拓扑，能够通过检索逻辑卷的iSCSI启动器名等于iSCSI目标器的允许连接iSCSI启动器、且卷内的iSCSI目标器ID等于iSCSI目标器内的ID的组合来获取。
[0149]图16中示出了管理服务器30000的装置信息获取模块33200实施的装置信息获取处理的流程图。
[0150]程序控制模块33100在程序起动时或每次从上次的装置信息获取处理起经过一定时间时，对装置信息获取模块33200指示执行装置信息获取处理。此外，在重复该执行指示的情况下不需要严格每隔一定期间，只要重复即可。另外。在从装置获取的信息中包含装置的结构信息、状态信息、性能信息，但也可以在分别不同的定时来获取这些信息。
[0151]装置信息获取模块33200对一个以上管理对象装置的每一个，重复以下的一系列处理(步骤61010)。
[0152]装置信息获取模块33200对管理对象装置指示发送装置的结构信息、状态信息或性能信息(步骤61020)。
[0153]如果有来自装置的响应(步骤61030)，则装置信息获取模块33200将所获取的结构信息与保存在结构DB33700中的过去的结构信息进行比较(步骤61040)。此外，在没有从装置对指示的响应的情况下，结束结构信息获取处理。
[0154]在将所获取的结构管理信息与保存在结构DB中的过去的结构信息进行比较的结果为发现了不同项目的情况下(步骤61050)，装置信息获取模块33200将有差异的项目事件化，并更新事件管理表33100 (步骤61060)。
[0155]接着，装置信息获取模块33200将在获取状态信息、性能信息时检测到的状态异常及性能异常事件化，并更新事件管理表33100 (步骤61070)。然后，装置信息获取模块33200将所获取的结构信息保存在结构DB33700中(步骤61080)。
[0156]以上是信息获取模块33200实施的结构管理信息获取处理。此外，向进行因果律的展开或删除的模块进行的结构变更的通知(或模块的执行开始)，不必需要通过事件来进行。另外，所谓基于状态信息的事件化，在组件的状态变化成正常以外的状态时生成与变化目标的状态对应的事件(信息)，这是一例。另外，所谓基于性能信息的事件化，在利用预定的评价基准(阈值等)而为不正常的性能值的情况下生成事件(信息)，这是一例。
[0157]接着，将管理服务器30000具有的展开对象事件传播模型管理表33600示出在图18中，将管理服务器30000执行的处理方式示出在图19、图20以及图21中。
[0158]图18是表示管理服务器30000具有的展开对象事件传播模型管理表33600的构成例的图。
[0159]展开对象事件传播模型管理表33600作为构成项目而包含:将所获取的结构变更事件产生的装置的类别进行登记的字段33610、将所述事件产生的装置内的组件的类别进行登记的字段33620、将所述事件的类别进行登记的字段33630、将通过后述的事件分析处理模块32500处理事件时哪个事件传播模型成为展开对象进行登记的字段33640。
[0160]图18中示出了管理服务器具有的展开对象事件传播模型管理表的具体值的一例。即，在发生了主计算机中的逻辑卷的状态异常这一事件的情况下，需要再次展开Rulel。
[0161]图19中示出了管理服务器30000的事件分析处理模块32400实施的事件确认处理的流程图。此外，管理服务器30000的装置信息获取模块33200，在对管理对象装置实施了图16所示的装置信息获取处理之后，对事件分析处理模块32400指示进行事件确认处理。
[0162]事件分析处理模块32400参照事件管理表33100，对事件管理表所定义的结构变更事件重复循环内的处理(步骤64010)。事件分析处理模块32400确认事件管理表所定义的事件的已处理标志是否为No (步骤64020)。在事件的已处理标志为No即为未处理事件的情况下，进行步骤64030至64060的处理。
[0163]事件分析处理模块32400将事件管理表所定义的事件的已处理标志变更为Yes (步骤64030)。接着事件分析处理模块32400确认事件管理表所定义的事件是否为结构变更事件(步骤64040)。在事件管理表所定义的事件为结构变更事件的情况下，执行图21所示的事件传播模型再展开处理。
[0164]接着事件分析处理模块32400确认事件管理表所定义的事件是否为状态异常或性能异常事件(结构变更事件以外)(步骤64050)。在事件管理表所定义的事件为状态异常或性能异常事件(结构变更事件以外)的情况下，对事件传播模型展开模块33600指示指定该事件来执行图20所示的事件传播模型按需展开处理。
[0165]当事件传播模型按需展开处理结束后，事件分析处理模块32400设定事件管理表的事件有效期间(步骤64060)。事件有效期间通过在事件发生的时刻上加上预定的一定时间而算出。但是，事件有效期间也可以利用其他算式来算出。
[0166]以上是事件分析处理模块32400实施的事件确认处理。
[0167]此外，在事件管理表中存在多个状态异常或性能异常事件的情况下，也可以指示事件传播模型展开模块同时对多个事件执行事件传播模型按需展开处理。
[0168]图20中示出了管理服务器30000的事件传播模型展开模块33600实施的事件传播模型按需展开处理的流程图。
[0169]事件传播模型展开模块33600参照展开对象事件传播模型管理表33600来获取与处理起动时所指定的事件(即，未处理事件之一)对应的事件传播模型的一览(步骤65010)。
[0170]接着，事件传播模型展开模块33600对所述获取的事件传播模型重复步骤65030至65090的处理(步骤65020)。此外，在展开对象事件传播模型管理表33600中没有登记事件的情况下，不执行以下的处理而结束事件传播模型按需展开处理。
[0171]事件传播模型展开模块33600参照拓扑生成方式库33400，从拓扑生成方式库33400获取与事件传播模型对应的拓扑生成方式(步骤65030)。在该相应的拓扑生成方式不在拓扑生成方式库中的情况下，不进行以下的处理。
[0172]如果该相应的拓扑生成方式存在于拓扑生成方式库中(步骤65040)，则事件传播模型展开模块33600基于所获取的拓扑生成方式从结构DB33700获取拓扑(步骤65050)。事件传播模型展开模块33600基于所获取的拓扑来展开事件传播模型(步骤65060)，确认展开结果是否已经存在于因果律矩阵33900中(步骤65070)。在展开结果已经存在于因果律矩阵33900中的情况下，不进行以下的处理。
[0173]在展开结果没有存在于因果律矩阵中的情况下，添加事件传播模型展开模块33600为因果律矩阵33900的列(步骤65080)。接着，事件传播模型展开模块33600对展开结果的结论事件和处理起动时所指定的事件以外的条件事件，实施图20所示的事件传播模型按需展开处理(步骤65090)。
[0174]以上是事件传播模型展开模块33600实施的事件传播模型按需展开处理。此外，在结构DB以外的信息中另行保存有拓扑的情况下也可以参照这样信息来进行上述处理。
[0175]图21中示出了管理服务器30000的事件传播模型展开模块33600实施的事件传播模型再展开处理的流程图。
[0176]事件传播模型展开模块33600将因果律矩阵33900全部删除(步骤66010)。接着，对于事件类别为结构变更的事件，将事件已处理标志变更为Yes (步骤66020)。
[0177]接着，事件传播模型展开模块33600参照事件管理表33100，对事件管理表中已处理的处理变更事件重复循环内的处理(步骤66030)。
[0178]事件传播模型展开模块33600确认该相应的事件的类别是否为状态异常或性能异常(即结构变更以外)(步骤66040)。接着，确认该相应的事件的事件有效期间是否到期(步骤66050)。在没有到期的情况下，指定该事件来实施事件传播模型按需展开处理65000 (步骤 66060)。
[0179]以上为事件传播模型展开模块33600实施的事件传播模型再展开处理。此外，本流程中一次删除全部因果律，对有效期间内的事件再次生成因果律，但也可以在步骤66010中仅删除与结构变更有关的因果律。
[0180]以下，以与图6至13的信息的内容对应的计算机系统为例，表示实施例1的处理如何生成因果律矩阵。此外，处理开始当初的iSCSI目标器管理表设为图8A所示那样。
[0181]程序控制模块根据来自管理者的指示或定时器的时间设定，对装置信息获取模块指示执行装置信息获取处理。装置信息获取模块依次登录到管理对象装置，对装置指示发送装置的结构信息、状态信息、性能信息。
[0182]在上述的处理结束之后，装置信息获取模块参照所获取的状态信息、性能信息来更新事件管理表。在此，如图12的事件管理表的第I行所示那样，假设检测到主计算机HOSTl的由(E:)所表示的逻辑卷的状态异常的情形。
[0183]事件分析处理模块在确认上述事件为未处理事件时，对事件传播模型展开模块指示参照展开对象事件传播模型管理表指定该事件来执行事件传播模型按需展开处理。
[0184]事件传播模型展开模块获取与事件对应的事件传播模型的一览。例如，参照图18所示的展开对象事件传播模型管理表，在产生了主计算机中的逻辑卷的状态异常这一事件的情况下，可知需要展开Rulel。
[0185]图13A所示的事件传播模型Rulel，作为观测事件定义了“主计算机的逻辑卷的状态异常”和“存储装置的卷的状态异常”。参照图15A所示的拓扑生成方式，定义了以存储装置的I/O端口为起点、以主计算机的逻辑卷为终点的拓扑生成方式TP1。因此，利用该拓扑生成方式来获取拓扑。
[0186]参照图7所示的卷管理表(与其相当的管理服务器所保存的结构DB内的项目)，着眼于存储装置SYSl的卷VOLl时，其目标器ID为TGl。接着，参照图8所示的iSCSI目标器管理表(与其相当的管理服务器所保存的结构DB内的项目)，寻找iSCSI目标器ID为TGl的项目，当看到该连接目标iSCSI启动器名时为“com.hitach1.svl”或“com.hitach1.svl I”。
[0187]接着，参照图6A所示的I/O端口管理表(与其相当的管理服务器所保存的结构DB内的项目)，检索iSCSI启动器名为“com.hitach1.svl”或“com.hitach1.svl I”的逻辑卷。在其结果检索到的主计算机HOSTl的逻辑卷(E:)和(F:)中，寻找LUN ID等于存储装置SYSl的卷VOLl的LUN ID的项目。以上的结果，作为包含主计算机的逻辑卷和存储装置的卷的拓扑之一，存在主计算机HOSTl的逻辑卷(E:)和存储装置SYSl的卷VOLl的组合。
[0188]于是，在作为观测事件检测到“主计算机HOSTl的逻辑卷(E:)的状态异常”和“存储装置SYSl的卷VOLl的状态异常”时，作为根本原因而得到结论为“存储装置SYSl的卷VOLl的故障”的模式成为展开结果(即应展开的因果律)。在该展开结果不存在于因果律矩阵中的情况下，将展开结果添加为因果律矩阵的列。
[0189]在上述的处理结束之后，对于展开结果的结论事件和输入事件以外的条件事件，实施图20所示的事件传播模型按需展开处理。在上述的展开结果的情况下，对于“存储装置SYSl的卷VOLl的故障”这一事件，参照图18所示的展开对象事件传播模型管理表，可知需要再展开Rule2。因此，以“存储装置SYSl的卷VOLl的故障”这一事件为起点，对于Rule2进行再次展开。
[0190]通过以上的处理，生成与事件传播模型Rulel及Rule2有关的因果律矩阵，分别成为图14C及图14D的状态。
[0191]另一方面，装置信息获取模块参照保存在结构DB中的过去的结构信息和由管理对象装置获取的结构信息来更新事件管理表。在此，如图12的事件管理表的第2行所示那样，假设检测到存储装置SYSl的由TGl所表示的iSCSI目标器的允许连接iSCSI启动器的变更的情形。此外，将变更后的iSCSI目标器管理表示出在图SB中。
[0192]接着，事件分析处理模块将事件管理表所定义的事件的已处理标志变更为Yes。接着事件分析处理模块确认事件管理表所定义的事件是否为结构变更事件。在事件管理表所定义的事件为结构变更事件的情况下，执行事件传播模型再展开处理。
[0193]事件传播模型展开模块将因果律矩阵全部删除，对于事件类别为结构变更的事件，将事件已处理标志变更为Yes。接着，事件传播模型展开模块参照事件管理表，对于事件的类别为状态异常、性能异常且事件有效期间没有到期的事件，实施事件传播模型按需展开处理。
[0194]例如，在图12的事件管理表的第I行目中定义有“主计算机HOSTl的由(E:)所表示的逻辑卷的状态异常”这一事件，将事件已处理标志设为Yes，事件有效期间被定义为“2010-01-01 15:30:00”。因此，事件传播模型展开模块以上述事件为起点来进行事件传播模型按需展开。也就是说，展开事件传播模型Rulel并添加到因果律矩阵中。展开的方法与事件传播模型按需展开处理的说明中说明的方法相同。
[0195]通过以上的处理，与事件传播模型Rulel有关的因果律矩阵被更新，成为图14C?图14E的状态。
[0196]实施例2
[0197]在实施例2中，对管理程序的事件传播模型展开模块33600实施的其他的事件传播模型按需展开处理进行说明。
[0198]在实施例1中，对事件传播模型展开模块指示同时对多个事件执行事件传播模型按需展开处理。在IT系统中，I个故障波及大量装置，由管理程序同时检测到大量异常事件。但是，对于具有相同根本原因的异常事件，若并行地处理事件传播模型按需展开处理，则会由结构DB同时获取多个相同拓扑，处理上的浪费多，处理时间变长。
[0199]为了解决上述的问题，在实施例2中变更管理服务器30000中的事件传播模型按需展开处理。将变更后的管理服务器30000具有的已展开事件管理表33700示出在图22中，将已展开起点组件管理表33800示出在图23中，将管理服务器30000执行的处理示出在图24A及图24B中。此外，其他与实施例1同样。
[0200]图22是表示在实施例2中保存在管理服务器30000的存储资源中的已展开事件管理表33700的构成例的图。
[0201]已展开事件管理表33700作为构成项目而包含:将成为已展开事件产生的装置的标识符的装置ID进行登记的字段33710、将事件产生的装置内的部位的标识符进行登记的字段33720、将所述事件的类别进行登记的字段33730、和将以所述事件为契机的展开处理的进展状况进行登记的字段33740。
[0202]图22中示出了管理服务器具有的展开对象事件传播模型管理表的具体值的一例。即，示出了以主计算机HOSTl中的逻辑卷(E:)的状态异常这一事件为契机的展开处理已经完成的情形。
[0203]图23是表示在实施例2中保存在管理服务器30000的存储资源中的已展开起点组件管理表33800的构成例的图。
[0204]已展开起点组件管理表33800作为构成项目而包含:将成为已展开起点组件所在的装置的标识符的装置ID进行登记的字段33810、将起点组件的标识符进行登记的字段33820、将以所述组件为起点进行了展开的事件传播模型的ID进行登记的字段33830、将以所述事件为契机的展开处理的进展状况进行登记的字段33840。
[0205]图23中示出了管理服务器具有的展开对象事件传播模型管理表的具体值的一例。即，示出了以存储装置SYSl中的卷VOLl这一组件为起点的Rulel的展开处理已经完成的情形。
[0206]将在本实施例中管理服务器30000执行的事件传播模型按需展开处理的处理方式示出在图24A及图24B中。此外，管理服务器30000执行的其他处理与实施例1相比没
有变化。
[0207]图24A及图24B中示出了实施例2中的管理服务器30000的事件传播模型展开模块33600实施的事件传播模型按需展开处理的流程图。首先从图24A的处理开始说明。
[0208]事件传播模型展开模块33600参照已展开事件管理表33700，检索处理起动时指定的事件是否存在(步骤67010)。在事件存在且其状态为“已展开”的情况下，什么也不做而结束处理。在事件存在且其状态为“展开中”的情况下，待机一定时间之后再尝试进行处理。在已展开事件管理表33700中不存在事件的情况下，实施以下所示的处理(步骤67020)。
[0209]事件传播模型展开模块33600在已展开事件管理表33700中添加事件，将事件的状态变更为“展开中”(步骤67030)。接着，参照展开对象事件传播模型管理表33600，获取与所产生的事件对应的事件传播模型的一览(步骤67040)。
[0210]接着，事件传播模型展开模块33600对所述获取的事件传播模型重复图24B所记载的步骤67060至步骤67140的处理(步骤67050)。此外，在展开对象事件传播模型管理表33600中没有登记事件的情况下，不进行以下的处理而结束事件传播模型按需展开处理。
[0211]以下为图24B的说明。
[0212]事件传播模型展开模块33600参照拓扑生成方式库33400，从拓扑生成方式库33400获取与事件传播模型对应的拓扑生成方式(步骤67060)。在该相应的拓扑生成方式库不存在于获取信息库中的情况下，不进行以下的处理。
[0213]如果该相应的拓扑生成方式存在于拓扑生成方式库中(步骤67070)，事件传播模型展开模块33600基于所获取的拓扑生成方式，获取与事件产生的组件对应的起点组件(步骤 67080)。
[0214]接着，事件传播模型展开模块33600参照已展开起点组件管理表33800，检索是否存在起点组件(步骤67010)。在存在起点组件且其状态为“已展开”的情况下，什么也不做而结束处理。在存在起点组件且其状态为“展开中”的情况下，待机一定时间之后再次尝试进行处理。在已展开起点组件管理表33800中不存在起点组件的情况下，实施以下所示的处理(步骤67090)。
[0215]事件传播模型展开模块33600在已展开起点组件管理表33800中添加起点组件，将起点组件的状态变更为“展开中”(步骤67100)。
[0216]事件传播模型展开模块33600基于所获取的生成方式库从结构DB33700获取拓扑，基于所获取的拓扑来展开事件传播模型(步骤67110)。然后将展开结果添加为因果律矩阵33900的列(步骤67120)。接着，参照已展开起点组件管理表33800，将起点组件的状态变更为“已展开”(步骤67130)。
[0217]接着，对于展开结果的结论事件和处理起动时所指定的事件以外的条件事件，重复实施规则按需展开处理(步骤67140)。
[0218]到此为止为图24B的说明。再次返回到图24A进行说明。
[0219]在对事件传播模型的处理结束的时刻，参照已展开事件管理表33700，将所产生的事件的状态变更为“已展开”(步骤67150)。
[0220]以下以与图6至13的信息的内容对应的计算机系统为例，表示实施例1的处理如何生成因果律矩阵。
[0221]程序控制模块根据来自管理者的指示或由定时器进行的时间设定，对装置信息获取模块指示执行装置信息获取处理。装置信息获取模块依次登录到管理对象装置，对管理对象装置指示发送装置的结构信息、状态信息、性能信息。
[0222]在上述的处理结束之后，装置信息获取模块参照所获取的状态信息、性能信息来更新事件管理表。在此，如图12的事件管理表的第4行所示那样，假设检测到存储装置SYSl的由DISKl所表示的盘的状态异常的情形。
[0223]事件分析处理模块参照展开对象事件传播模型管理表，在确认到上述事件为未处理事件时，对事件传播模型展开模块指示指定该事件来执行事件传播模型按需展开处理。
[0224]事件传播模型展开模块参照已展开事件管理表来检索处理起动时所指定的事件是否存在。在已展开事件管理表中不存在事件的情况下，在已展开事件管理表中添加事件，将事件的状态变更为“展开中”。
[0225]接着，事件传播模型展开模块获取与事件对应的事件传播模型的一览。例如，参照图18所示的展开对象事件传播模型管理表，在产生了存储装置中的盘的状态异常这一事件的情况下，可知需要展开Rule2。
[0226]图13A所示的事件传播模型Rule2，作为观测事件而定义了 “存储装置的卷的故障”、“存储装置的RAID组的状态异常”、“存储装置的盘的状态异常”。参照图15B所示的拓扑生成方式，定义了以存储装置的RAID组为起点、以存储装置的卷和存储装置的盘为终点的拓扑生成方式TP2。因此，利用该拓扑生成方式来获取拓扑。
[0227]参照图10所示的RAID组管理表(与其相当的结构DB的项目)，着眼于存储装置SYSl的盘DISKl时，与其对应的RAID组为RGl。由此，可知成为与存储装置SYSl的盘DISKl对应的起点的存储装置的RAID组为RGl。接着,参照图24所示的已展开起点组件管理表，检索存储装置SYSl的RAID组RGl是否已登记，如果没有登记则将状态新登记为“展开中”。
[0228]接着，参照图7所示的卷管理表(与其相当的结构DB的项目)，检索RAID组ID为RGl的卷。其结果可知存在检索到的存储装置SYSl的卷VOLl和V0L2。以上的结果，作为包含存储装置的卷、RAID组和盘的拓扑，存在存储装置SYSl的盘DISKl、RAID组RGl、卷VOLl的组合。
[0229]因此，在作为观测事件检测到“存储装置SYSl的盘DISKl的状态异常”、“存储装置SYSl的RAID组RGl的状态异常”和“存储装置SYSl的卷VOLl的故障”时，作为根本原因而归结为“存储装置SYSl的盘DISKl的故障”的模式成为展开结果。将该展开结果添加为因果律矩阵的列。
[0230]在上述的处理结束之后，对于展开结果的结论事件和输入事件以外的条件事件，实施规则按需展开处理。在上述的展开结果的情况下，对于“存储装置SYSl的卷VOLl的故障”这一事件，参照图18所示的展开对象事件传播模型管理表，可知需要再次展开Rulel。因此，对于Rule2再次进行展开。
[0231]通过以上的处理，生成与事件传播模型Rulel及Rule2有关的因果律矩阵，分别成为图14C及图14D的状态。
[0232]然后，在管理程序再次检测到“存储装置SYSl的盘DISKl的状态异常”这一事件，并从事件分析处理模块对事件传播模型展开模块指示指定该事件来执行事件传播模型按需展开处理的情况下，事件传播模型展开模块参照已展开事件管理表来检索处理起动时所指定的事件是否存在。由于在已展开事件管理表中存在事件且事件的状态为“已展开”，所以不进行之后的处理而结束事件传播模型按需展开处理。
[0233]或者，在管理程序检测到“存储装置SYSl的盘DISK2的状态异常”这一事件，并从事件分析处理模块对事件传播模型展开模块指示指定该事件来执行事件传播模型按需展开处理的情况下，事件传播模型展开模块参照已展开事件管理表来检索处理起动时所指定的事件是否存在。由于在已展开事件管理表中不存在事件，所以判断为事件传播模型展开模块需要参照展开对象事件传播模型管理表来展开事件传播模型Rule2。
[0234]图13A所示的事件传播模型Rule2，作为观测事件而定义了 “存储装置的卷的故障”、“存储装置的RAID组的状态异常”、“存储装置的盘的状态异常”。参照图15B所示的拓扑生成方式，定义了以存储装置的RAID组为起点、以存储装置的卷和存储装置的盘为终点的拓扑生成方式TP2。因此，利用该拓扑生成方式来获取拓扑。
[0235]参照图10所示的RAID组管理表(与其相当的结构DB的项目)，着眼于存储装置SYSl的盘DISK2时，与其对应的RAID组为RG1。由此，可知成为与存储装置SYSl的盘DISKl对应的起点的存储装置的RAID组为RG1。接着，参照图23所示的已展开起点组件管理表，由于存在存储装置SYSl的RAID组RG1、且起点组件的状态为“已展开”，所以不进行之后的处理而结束事件传播模型按需展开处理。
[0236]此外，如图29所示，在计算机系统上存在多台管理服务器30000，分担管理存储装置20000、主计算机10000、管理服务器30000这样的管理对象装置的情况下，在已展开事件管理表33700中不存在处理起动时所指定的事件时，管理服务器30000的事件传播模型展开模块33600参照其他的管理服务器上的已展开事件管理表来检索该事件是否存在。在该事件存在的情况下，从该管理服务器上的因果律矩阵33900收集与该事件关联的行及列，并复制到自身的因果律矩阵中。
[0237]以上为本实施例中的事件传播模型按需展开处理。
[0238]根据以上的本实施例，管理程序在展开事件传播模型之前检索与所检测到的事件以及要展开的事件传播模型对应的结论组件，对各结论组件中已完成规则展开的结论组件或展开中的结论组件进行记录，由此抑制从相同事件传播模型重复生成相同因果律矩阵。
[0239]作为其结果，在以大规模系统为对象并采用按需展开方式的分析引擎中，即使在同时接收到具有相同故障原因的大量故障的情况下，也能够使基于事件传播模型的因果律矩阵的展开作业高效化，能够减轻对管理服务器施加的处理负荷同时适当地执行因果律矩阵的展开处理。
[0240]实施例3
[0241]在实施例3中，对管理程序的事件传播模型展开模块33600实施的事件传播模型展开处理进行说明。
[0242]在实施例1中，管理程序从装置接收到异常事件之后执行事件传播模型按需展开处理，在该事件传播模型按需展开处理结束之后实施故障分析。因此，存在从接收到事件到开始故障分析的时间比以往的事先展开方式长的问题。另一方面，例如在仅与存储装置内的物理组件(端口、盘等)有关的事件传播模型的情况下，由于展开时所获取的拓扑变化的频率非常低，所以即使采用以往的事先展开方式，因结构变更而被迫再展开的可能性也非常低，为了在接收到事件后更迅速地开始故障分析，优选采用事先展开方式。
[0243]为了解决这样的问题，在实施例3中变更管理服务器30000中的事件传播模型按需展开处理及事件传播模型再展开处理。将实施例3的管理服务器30000具有的事件传播模型管理表33900示出在图25中，将管理服务器30000执行的处理流程示出在图26至图28中。此外，管理服务器30000的其他信息及流程与实施例1或2相同。
[0244]图25是表示在实施例3中管理服务器30000具有的事件传播模型管理表33900的构成例的图。
[0245]事件传播模型管理表33900作为构成项目而包含:将成为事件传播模型的标识符的事件传播模型ID进行登记的字段33910、和将用于所述事件传播模型的展开的方式进行登记的字段33920。
[0246]图25中示出了管理服务器具有的事件传播模型管理表的具体值的一例。即，示出了对于由事件传播模型ID为Rulel所表示的事件传播模型通过事先展开方式来展开的情形。
[0247]将在本实施例中管理服务器30000执行的事件传播模型按需展开处理的处理方式示出在图26中。此外，管理服务器30000执行的其他处理与实施例1相比没有变化。
[0248]图26中示出了实施例3中的管理服务器30000的事件传播模型展开模块33600实施的事件传播模型按需展开处理的流程图。与实施例1的图20中所说明的流程不同之处在于添加了步骤65021及步骤65022。以下，仅说明被添加的部分。
[0249]事件传播模型展开模块33600参照事件传播模型管理表33900来获取事件传播模型的展开方式(步骤65021)。在展开方式为“按需展开”的情况下(步骤65022)，执行步骤65030。
[0250]图28中示出了实施例3中的管理服务器30000的事件传播模型展开模块33600实施的事件传播模型展开处理的流程图。此外，处理在实施例1中说明的图21的处理的步骤66020与步骤66030之间执行。
[0251]事件传播模型展开模块33600对在事件传播模型库33700中定义的全部事件传播模型重复步骤63022至63060的处理(步骤63020)。
[0252]事件传播模型展开模块33600参照事件传播模型管理表33900来获取事件传播模型的展开方式(步骤63021)。在展开方式为“事先展开”的情况下(步骤63022)，执行以下的处理。
[0253]事件传播模型展开模块33600参照拓扑生成方式库33400，从拓扑生成方式库33400获取与事件传播模型对应的拓扑生成方式(步骤63030)。
[0254]如果该相应的拓扑生成方式存在于拓扑生成方式库中(步骤63040)，事件传播模型展开模块33600基于所获取的拓扑生成方式从结构DB33700获取拓扑(63050)，使用所获取的拓扑来展开事件传播模型，并添加到因果律矩阵33900中(步骤63060)。
[0255]以上为事件传播模型展开模块33600实施的事件传播模型展开处理。
[0256]此外，在本实施例中对每个事件传播模型定义了使用按需展开方式和事先展开方式中的哪一方，但例如也可以按每个管理对象装置来进行所述的定义。即，能够以对于想在故障产生后立即求出根本原因的重要的装置采用事先展开方式，对于其他装置采用按需展开方式的方式来分开使用。
[0257]根据以上本实施例，基于在管理程序的事件传播模型管理表中登记的策略，对于各个事件传播模型，能够选择使用实施例1中所述的按需展开方式和事先展开方式的哪一方。作为结果，能够根据以何种程序来求出事件传播模型的性质和/或分析作业的实时性来分开使用两个方式。
[0258]附图标记说明
[0259]10000:服务器，20000:存储装置，30000:管理服务器，40000:1P交换机，45000:
网络
【权利要求】
1.一种管理计算机，包含保存有管理程序的存储资源和执行所述管理程序的处理器，对多个管理对象计算机进行管理，该管理计算机的特征在于，所述存储资源保存有: (1)拓扑，其对于多个管理目标表示所述多个管理目标彼此的关系，所述多个管理目标为所述多个管理对象计算机或所述多个管理计算机所包含的多个组件； (2)事件传播模型，其表示因在类别I的管理目标中发生的类别A的事件的原因而在类别2的管理目标中发生类别B的事件；和 (3)包含一个以上因果律的因果律信息， 所述因果律表示因在类别为类别I的第I管理目标中发生的类别为类别A的第I事件的原因而在类别为类别2的第2管理目标中发生类别为类别B的第2事件， 所述管理程序使所述处理器进行: (A)检测与在预定的管理目标中发生的问题有关的事件， (B)判断用于分析所述检测事件的预定的因果律在所述因果律信息中是否已生成， (C)在(B)中判断为未生成的情况下，基于所述拓扑和所述事件传播模型进行在所述因果律信息中生成所述预定的因果律的按需展开， (D)使用所述预定的因果律来分析所述检测事件。
2.根据权利要求1所述的管理计算机，其特征在于， 所述存储资源保存有 : (3)事件传播模型管理信息，其表示是否事先执行与所述事件传播模型对应的因果律的生成， 在所述管理计算机检测事件之前，所述管理程序使所述处理器进行: (E)基于所述事件传播模型管理信息来判断是否事先生成所述因果律。
3.根据权利要求2所述的管理计算机，其特征在于， 所述存储资源保存有: (4)可否事先展开信息，其表示是否事先执行与所述管理目标对应的因果律的生成， 在所述管理计算机检测事件之前，所述管理程序使所述处理器进行: (F)基于所述可否事先展开信息来判断是否事先生成与所述预定的管理目标对应的所述因果律。
4.根据权利要求3所述的管理计算机，其特征在于， 所述存储资源保存有: (5)与所述检测事件有关的分析有效期间， 所述分析有效期间期满后，所述管理程序使所述处理器进行: (G)将与所述检测事件对应的所述预定的因果律从所述因果律信息中删除。
5.根据权利要求4所述的管理计算机，其特征在于， 所述管理程序使所述处理器进行: (H)在与所述预定的因果律有关的按需展开中，抑制具有与所述预定的因果律表示的原因事件相同原因的其他因果律的按需展开。
6.一种事件分析方法，是由管理多个管理对象计算机的包含存储资源的管理计算机进行的事件分析方法，其特征在于， 所述存储资源中保存有:(1)拓扑，其对于多个管理目标表示所述多个管理目标彼此的关系，所述多个管理目标为所述多个管理对象计算机或所述多个管理计算机所包含的多个组件； (2)事件传播模型，其表示因在类别I的管理目标中发生的类别A的事件的原因而在类别2的管理目标中发生类别B的事件；和 (3)包含一个以上因果律的因果律信息， 所述因果律表示因在类别为类别I的第I管理目标中发生的类别为类别A的第I事件的原因而在类别为类别2的第2管理目标中发生类别为类别B的第2事件， 所述事件分析方法中， (A)检测与在预定的管理目标中发生的问题有关的事件， (B)判断用于分析所述检测事件的预定的因果律在所述因果律信息中是否已生成， (C)在(B)中判断为未生成的情况下，基于所述拓扑和所述事件传播模型进行在所述因果律信息中生成所述预定的因果律的按需展开， (D)使用所述预定的因果律来分析所述检测事件。
7.根据权利要求6所述的事件分析方法，其特征在于， 所述存储资源中保存有: (3)事件传播模型管理信 息，其表示是否事先执行与所述事件传播模型对应的因果律的生成， 所述事件分析方法中， (E)在所述管理计算机检测事件之前，基于所述事件传播模型管理信息来判断是否事先生成所述因果律。
8.根据权利要求6所述的事件分析方法，其特征在于， 所述存储资源中保存有: (4)可否事先展开信息，其表示是否事先执行与所述管理目标对应的因果律的生成， 所述事件分析方法中， (F)在所述管理计算机检测事件之前，基于所述可否事先展开信息来判断是否事先生成与所述预定的管理目标对应的所述因果律。
9.根据权利要求6所述的事件分析方法，其特征在于， 所述存储资源中保存有: (5)与所述检测事件有关的分析有效期间， 所述事件分析方法中， (G)所述分析有效期间期满后，将与所述检测事件对应的所述预定的因果律从所述因果律信息中删除。
10.根据权利要求6所述的管理计算机，其特征在于， (H)在与所述预定的因果律有关的按需展开中，抑制具有与所述预定的因果律表示的原因事件相同原因的其他因果律的按需展开。
11.一种计算机系统，具有多个管理对象计算机和管理所述多个管理对象计算机并包含存储资源的管理计算机，其特征在于， 所述存储资源保存有: (I)拓扑，其对于多个管理目标表示所述多个管理目标彼此的关系，所述多个管理目标为所述多个管理对象计算机或所述多个管理计算机所包含的多个组件； (2)事件传播模型，其表示因在类别I的管理目标中发生的类别A的事件的原因而在类别2的管理目标中发生类别B的事件；和 (3)包含一个以上因果律的因果律信息， 所述因果律表示因在类别为类别I的第I管理目标中发生的类别为类别A的第I事件的原因而在类别为类别2的第2管理目标中发生类别为类别B的第2事件， 所述管理计算机进行: (A)检测与在预定的管理目标中发生的问题有关的事件， (B)判断用于分析所述检测事件的预定的因果律在所述因果律信息中是否已生成， (C)在(B)中判断为未生成的情况下，基于所述拓扑和所述事件传播模型进行在所述因果律信息中生成所述预定的因果律的按需展开， (D)使用所述预定的因果律来分析所述检测事件。
12.根据权利要求11所述的计算机系统，其特征在于， 所述存储资源保存有: (3)事件传 播模型管理信息，其表示是否事先执行与所述事件传播模型对应的因果律的生成， 在所述管理计算机检测事件之前，所述管理计算机进行: (E)基于所述事件传播模型管理信息来判断是否事先生成所述因果律。
13.根据权利要求11所述的计算机系统，其特征在于， 所述存储资源保存有: (4)可否事先展开信息，其表示是否事先执行与所述管理目标对应的因果律的生成， 在所述管理计算机检测事件之前，所述管理计算机进行: (F)基于所述可否事先展开信息来判断是否事先生成与所述预定的管理目标对应的所述因果律。
14.根据权利要求11所述的计算机系统，其特征在于， 所述存储资源保存有: (5)与所述检测事件有关的分析有效期间， 所述分析有效期间期满后，所述管理计算机进行: (G)将与所述检测事件对应的所述预定的因果律从所述因果律信息中删除。
15.根据权利要求11所述的计算机系统，其特征在于， 所述管理计算机进行: (H)在与所述预定的因果律有关的按需展开中，抑制具有与所述预定的因果律表示的原因事件相同原因的其他因果律的按需展开。
【文档编号】G06N5/04GK103477325SQ201180069912
【公开日】2013年12月25日 申请日期:2011年9月26日 优先权日:2011年9月26日
【发明者】永井崇之, 名仓正刚, 菅内公德, 黑田泽希 申请人:株式会社日立制作所