JP4130615B2 - Fault information management method and management server in a network having a storage device - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a computer system having a storage system. In particular, the present invention relates to a method and apparatus for managing a storage system failure in a storage area network (hereinafter referred to as SAN) in which a real volume provided from a storage system is provided to a server as a virtual volume. .
[0002]
[Prior art]
(1) About SAN
In recent years, SAN, which is a network dedicated to storage input / output that separates and aggregates storage from each server, is becoming popular. With the introduction of SAN, it has become possible to achieve high-speed data transfer, high scalability and availability of storage systems, and effective use of storage resources.
[0003]
(2) About SAN management
The high scalability of storage systems based on SANs has allowed devices from multiple vendors (servers, switches, storage devices) to be mixed in the SAN. In order to operate such a SAN without interruption, SAN management is required.
[0004]
An overview of SAN management is described in Non-Patent Document 1, for example. Among SAN management, it is particularly important to monitor the operational status of each device connected to the SAN, which is the basis of daily operations. The software for monitoring the operating status of the SAN is hereinafter referred to as the SAN manager.
[0005]
The SAN manager has two major functions: a configuration management function and a fault monitoring function.
[0006]
The configuration management function periodically acquires information from the management agent that exists in each device connected to the SAN, detects the physical connection relationship (topology) of the SAN from the acquired information, and always maintains the latest topology. This is a function that is visualized and provided to SAN manager users, in other words, SAN managers.
[0007]
The fault monitoring function is a fault or performance degradation based on event notifications such as hardware faults or performance degradation issued by each device connected to the SAN, or device information periodically acquired from the management agent that exists in each device. It is a function that grasps the occurrence of such events and notifies the SAN administrator of the events.
[0008]
With these two functions, the SAN manager can centrally manage the operation status of the devices using the SAN manager, so the operating cost can be reduced by reducing the number of SAN managers.
[0009]
(3) Virtualization device
There is a virtual volume technology as a storage management technology in the SAN. The virtual volume technique is disclosed in Patent Document 1. This patent document discloses that a device called a storage server has the following two functions.
[0010]
1) A function for managing a volume (hereinafter referred to as a real volume) that is a storage area in a storage medium of each storage device connected to a storage server and generating a volume pool.
[0011]
2) Create a virtual volume based on one or more real volumes in the volume pool, and convert I / O access to the virtual volume from the server to I / O requests to the real volume sequentially. A function that responds to I / O.
[0012]
The device having these two functions is hereinafter referred to as a virtualization device. By introducing the virtualization device to the SAN, the volume allocation to the server is unified by the virtual volume, and it becomes unnecessary to be aware of the physical arrangement of the storage device connected to the virtualization device. That is, the SAN administrator can perform volume allocation in a centralized manner.
[0013]
[Patent Document 1]
British Patent Application No. 2351375
[Non-Patent Document 1]
Richard Barker, Paul Massiglia, “Storage Area Network Essentials”, John Wiley & Sons, Inc, 2002, p.331- 334
[0014]
[Problems to be solved by the invention]
With the fault monitoring function of the SAN manager, the SAN manager performs the task of identifying which part of which device is the cause of the failure based on events issued from a plurality of devices. This is hereinafter referred to as “failure isolation”. By providing the virtual volume by the virtualization apparatus, the degree of freedom of configuration of the volume provided to the server increases. However, in order to isolate a failure based on a failure message (such as SNMP Trap) issued from a device of multiple vendors connected to the SAN, a manual operation by a SAN administrator with advanced knowledge of each device Relying on the current situation, there is a problem that the management cost is very high.
[0015]
Also, depending on the severity of the failure (hereinafter referred to as “Severity”), the SAN manager notifies the event to the management software that manages and manages the entire business system (hereinafter referred to as “high-level system management software”). It has a failure notification function such as sending e-mail. However, since the definition of failure severity depends on each device connected to the SAN, it is necessary for the SAN administrator to determine which event of which device has a higher severity each time. There is a problem.
[0016]
A first object of the present invention is to assist a SAN administrator in isolating a failure when a failure message is issued from a device connected to the SAN.
[0017]
The second object of the present invention is to enable a SAN administrator or higher system management software to receive necessary failure information among failure messages issued from devices connected to the SAN. That is.
[0018]
[Means for Solving the Problems]
For the first purpose, a management server that receives multiple failure notifications from a device connected to the SAN associates multiple failure notifications based on the correspondence between the real volume and virtual volume managed by the virtualization device. Output.
[0019]
In addition, for the second purpose, the management server that receives a plurality of failure notifications from devices connected to the SAN includes information indicating the importance of failure information based on different criteria included in the failure notification, It converts into the information which shows the importance based on a common reference | standard, and processes a failure notification based on the importance after conversion.
[0020]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings. However, this does not limit the present invention.
[0021]
<SAN configuration>
First, a configuration example of a SAN in this embodiment will be described. 1 to 6 show a configuration example of each device connected to the SAN and FIG. 9 to FIG. 18 show management information provided in each device.
[0022]
Fig. 1 shows an example of a SAN configuration. The SAN in the present invention includes one or more servers having a management agent, one or more switches having a management agent, one or more virtualization devices having a management agent, one or more storage devices having a management agent, and a SAN Has one SAN management server with a manager.
[0023]
For convenience of the following description, in the SAN of this embodiment, one server (server A) 20000, one switch (switch A) 30000, and one virtualization device / storage device (storage device A) Assume that 40000 and one storage device (storage device B 50000) are connected to each other via a fiber channel 60000. In this connection mode, the storage device A40000 recognizes the real volume 57000 of the storage device B50000 via the switch 30000 and applies the virtual volume function to the real volume 57000 of the storage device B50000 to the server. Provided as a virtualized volume of device A40000. Note that the connection form of the storage device A40000 and the storage device B50000 is not connected via the switch A30000 as in the example shown in FIG. 1, but for example, as in the second configuration example shown in FIG. With 60000, the storage apparatus A40000 and the storage apparatus B50000 may be directly connected. Further, as in the third configuration example shown in FIG. 27, a path to which the storage apparatus A40000 and the storage apparatus B50000 are directly connected and a path to which both storage apparatuses are connected via a switch may be mixed.
[0024]
The SAN management server 10000 is connected to each server, switch, and storage device via the management network 70000, and the management agent of each device communicates with the SAN manager 13100 in the SAN management server 10000 via the management network. it can. The SAN manager 13100 performs configuration management of the virtual volume and real volume in the SAN, fault isolation in the SAN, and fault notification in the SAN by processing described later.
[0025]
FIG. 2 shows a configuration example of the SAN management server 10000. The SAN management server 10000 is executed by a processor 11000, a memory 13000, a management interface control unit (hereinafter referred to as I / F) 14000 for connecting to the management network 70000, and a SAN manager 13100 to perform processing described later. Output unit 15000 such as a display device that outputs the execution result in the event of a failure, and an input unit 16000 such as a keyboard for the SAN administrator to input instructions to the SAN manager, which are communication paths 17000 such as an internal bus Are connected to each other.
[0026]
The memory 13000 includes a SAN manager 13100, which is a program executed by the SAN management server, a real volume mapping management table 13200 that holds real volume mapping information in the SAN, and a virtual volume mapping management that holds virtual volume mapping information in the SAN. Table 13300, real topology repository 13400, which is an area for storing information collected from the management agents provided in each device in the SAN, and a device that holds a list of devices managed by the SAN manager 13100 in the SAN Detection list 13500, one or more failure analysis dictionaries 13600 for interpreting the contents of failure notification messages received from each device in the SAN, a failure log 13700 for recording event contents, and a severity conversion function described later To perform the Severity conversion definition defined in advance by the SAN administrator. One or more failure severity conversion tables 13800 for holding are stored.
[0027]
FIG. 3 shows a configuration example of the server 20000. The server 20000 has a processor 21000, a memory 23000, a management I / F 24000 for connection to the management network 70000, and one or more data I / F 26000 for connection to the Fiber Channel 60000, which are internal They are connected to each other via a communication path 27000 such as a bus.
[0028]
The memory 23000 includes a management agent 23100 that is a program for communicating with the SAN manager 13100 to send and receive management information of the server, and a data I / F management table 23200 that holds management information of the data I / F of the server And a volume management table 23300 that holds management information of volumes accessed by the server.
[0029]
In this embodiment, the server is one server A and the server A has one data I / F. However, the number of servers and the number of data I / Fs are not limited to one, and there are a plurality of servers in the SAN. Even if connected, one server may be provided with a plurality of data I / Fs. Each server's data I / F is assigned a unique identifier (data I / F ID) within each server. In this embodiment, the value of the data I / F ID of server A is a1. .
[0030]
FIG. 4 shows a configuration example of the switch 30000. The switch 30000 includes a controller 31000 that realizes switching of data transmitted / received via the Fiber Channel 60000, a memory 33000, a management I / F 34000 for connection to the management network 70000, and a connection for the Fiber Channel 60000. The memory 33000, the management I / F 34000, and the data I / F 36000 are connected to each other via the controller 31000.
[0031]
The memory 33000 includes a management agent 33100, which is a program for communicating with the SAN manager 13100 to send and receive management information of the switch A, and a fiber channel 60000 between the switch and each server or each storage device. An FC connection management table 33200, which is information indicating a connection relationship, is stored.
[0032]
In this embodiment, the switch existing in the SAN is one switch A, and the switch A has six data I / Fs. However, the number of switches and the number of data I / Fs are any number. There may be. Each data I / F has a unique identifier (data I / F ID) in the apparatus (in the switch), and in the present embodiment, the values are s1, s2, s3, s4, s5, and s6.
[0033]
FIG. 5 shows a detailed configuration example of the storage apparatus A that is a virtualization apparatus and storage apparatus. The storage device A 40000 includes a controller 41000 for controlling the storage device, a memory 43000, a management I / F 44000 for connection to the management network 70000, and one or more data I for connection to the fiber channel 60000. / F46000 and one or more real volumes 47000 that are storage areas in the disk device for storing data used by the server, and the memory 43000, management I / F 44000, data I / F 46000, and real volume 47000 Are connected to each other via a controller 41000. FIG. 5 shows one or more virtual volumes 48000 in addition to the real volume 47000 as a storage area connected to the controller 41000. This virtual volume 48000 is obtained by virtualizing a real volume held by another storage device (for example, storage device B50000) using the virtual volume function of storage device A. The virtual volume 48000 is provided to the server as a volume of storage device A The storage area is displayed as a component of the storage apparatus A in FIG. 5, but the actual storage area exists in another storage apparatus connected to the storage apparatus A.
[0034]
The memory 43000 includes a management agent 43100 that is a program for communicating with the SAN manager 13100 to send and receive management information of the storage device A, and a data I / F management that holds management information of the data I / F of the storage device A A table 43200, a real volume management table 43300 for holding management information of the real volume 47000 of the storage device A, a virtual volume management program 43400 for realizing the virtual volume function, and the storage device provided to each server A virtual volume management table 43500 that holds management information of virtual volumes that are stored is stored.
[0035]
In this embodiment, the storage device A has two data I / Fs, two real volumes, and two virtual volumes, but the number of data I / Fs, real volumes, and virtual volumes is any number. May be. Each data I / F, each real volume, and each virtual volume has a unique identifier (data I / F ID, real volume ID, virtual volume ID) in the device. In this embodiment, the data I / F ID value is used. Assume that c1, c2, real volume ID values are va1, va2, and virtual volume ID values are vv1, vv2.
[0036]
FIG. 6 shows a detailed configuration example of the storage apparatus B. The storage apparatus B has the same configuration as the storage apparatus A except that it does not have a virtual volume function. Therefore, the virtual volume management program and the virtual volume management table do not exist in the memory 53000. In this embodiment, the storage apparatus B has two data I / Fs and three real volumes, but the number of data I / Fs and real volumes may be any number. In addition, the data I / F ID values of the storage apparatus B are d1, d2, and the volume ID values are vb1, vb2, vb3.
[0037]
FIG. 9 shows an example of a device detection list 13500 held by the SAN management server 10000. In the detection target ID column of FIG. 9, a number arbitrarily assigned in the SAN management server is registered, the type of device in the SAN is registered in the device type column, the vendor of each device, each device in the device information column In the IP address information column, the address on the management network 70000 of each device is registered, and in the virtualization function column, whether each device has a virtualization function is registered, In the virtualization target ID column, an entry in which storage is registered as device information, and when the real volume of the storage device is virtualized by another device, detection of the other device that performs the virtualization process is detected The target ID is registered. These pieces of information are set in advance by the SAN administrator using the output unit 15000 and the input unit 16000 of the SAN management server 10000. Based on this list, the SAN manager 13100 identifies the management agent of each device and communicates with the management agent.
[0038]
FIG. 10 shows an example of the data I / F management table held by the server A 20000. The data I / F ID value of each server is registered in the data I / F ID column of FIG. 10, and the fiber assigned to the data I / F in the Port WWN (World Wide Name) column. The Port WWN, which is a unique identifier within the channel, is registered, and the identifier (SCSI ID number) of the SCSI target device to which the data I / F is connected is registered in the SCSI ID column.
[0039]
FIG. 11 shows an example of a volume management table held by the server A 20000. Server A has been provided with three volumes, and server A holds information on the volumes that it has received in the volume management table. In the LU (Logical Unit) ID column of the volume management table, an identifier arbitrarily assigned to the volume provided by the server A itself is registered. In the Data I / F ID column, the identifier of the data I / F on the server A used for accessing the volume is registered, and in the SCSI ID column, the SCSI of the SCSI target device to which the data I / F is connected is registered. The ID number is registered, the SCSI logical unit number for accessing the volume in the SCSI target device is registered in the LUN column, and the volume for the server that can be acquired by the SCSI INQUIRY command, etc. in the volume information column Vendor name, device name, and identifier of the volume are registered.
[0040]
In the example of FIG. 11, the server A uses the real volume va1 from the storage device A and the virtual volume vv1 that exists in the storage B but is virtualized by the storage device A. The real volume vb3 is provided from the storage device B and used. Note that the real volume vb3 of the storage apparatus B is provided to the server A without being virtualized by the storage apparatus A.
[0041]
FIG. 12 shows an example of the FC connection management table 33300 held by the switch A 30000. The FC connection management table holds information related to the connection destinations s1 to s6, which are the data I / F of the switch A 30000. The data I / F ID value of switch A 30000 is registered in the data I / F ID column of the FC connection management table, and the port WWN of the data I / F is registered in the switch Port WWN column. In the WWN column, the port WWN of the data I / F on the server or storage device to which the data I / F is connected is registered.
[0042]
FIG. 13 shows an example of a data I / F management table held by the storage apparatus. The data I / F management table 43200 is a table that the storage apparatus A has, and the data I / F management table 53200 is a table that the storage apparatus B has. The data I / F identifier value of the storage apparatus is registered in the data I / F ID column of the data I / F management table, and the Port WWN of the data I / F is registered in the Port WWN column.
[0043]
FIG. 14 shows an example of a real volume management table held by the storage apparatus. The real volume management table 23300 is a table that the storage apparatus A has, and the real volume management table 53300 is a table that the storage apparatus B has. The real volume ID value of the storage device is registered in the real volume ID column of the real volume management table, and the presence / absence of the path used when another device accesses the real volume is registered in the path presence / absence column. In the data I / F ID column, the identifier value of the data I / F on the storage device used to access the volume is registered, and the SCSI ID column is assigned to the data I / F. The SCSI ID number is registered, and the SCSI logical unit number for accessing the real volume is registered in the SCSI LUN column. A real volume whose path is registered as “none” in the path presence / absence column in the real volume management table is an unused real volume. Therefore, “N / A” indicating that the values in the data I / F ID column, SCSI ID column, and SCSI LUN column are undefined is registered.
[0044]
FIG. 15 shows an example of the virtual volume management table 43500 held by the storage apparatus A 40000. First, the contents of the virtual volume column will be described. In the virtual volume ID column, an identifier arbitrarily assigned to the virtual volume provided to the server is registered, and in the path presence / absence column, the presence / absence of a path used when another device accesses the virtual volume is registered. Registered, the data I / F ID column registers the identifier value of the data I / F on the storage device used to access the volume, and the SCSI ID column assigns it to the data I / F. The SCSI ID number is registered, and the SCSI logical unit number for accessing the real volume is registered in the LUN column. In this embodiment, the storage apparatus A 40000 provides the virtual volume vv1 from the data I / F c1. The virtual volume vv2 is unused.
[0045]
Next, the contents of the real volume column of the virtual volume management table 43500 will be described. In the real data I / F ID column, the identifier of the data I / F on the storage device A that is used to access the real volume that constitutes the virtual volume indicated by the identifier registered in the virtual volume ID column Is registered. In the SCSI ID column, the SCSI ID number of the SCSI target device to which the actual data I / F is connected is registered. In the LUN column, the volume provided from the storage device is accessed via the actual data I / F. SCSI logical unit number is registered. Registered in the real volume information column is the name of the storage device that provides the real volume that can be obtained via the SCSI INQUIRY command and is accessed via the real data I / F, and the identifier and storage capacity of the real volume. Is done.
[0046]
In the virtual volume management table, only the volume data virtualized by the virtualization apparatus (for example, storage apparatus A) is registered. Therefore, the real volumes vb1 and vb2 that are accessible from the data I / F c2 and exist in the storage device B are recognized by the storage device A, virtualized by the storage device A, and provided to the server as virtual volumes. Registered in the volume management table. Further, since the real volume va1 accessible from the data I / F c1 is provided to the server without being virtualized in the storage apparatus A, information on va1 is not registered in the virtual volume management table 43500. In addition, since the real volume vb3 of the storage apparatus B is directly recognized by the server A via the data I / Fd2, information regarding vb3 is not registered in the virtual volume management table 43500. As described above, the virtualization device that holds the volume virtualization function may not virtualize the real volumes of all the storage devices.
[0047]
FIG. 16 shows an example of a failure analysis dictionary 13600 that the SAN management server 10000 has. (a) is the storage device A, (b) is the storage device B, (c) is the server A, and (d) is the failure analysis dictionary of the switch A. These dictionaries are used for analyzing an SNMP Trap message issued when a failure occurs from each device, and the details will be described later. The fault code column contains the fault code in the Variable Bindings field of the SNMP Trap message, the fault part column contains the fault part corresponding to each fault code, and the identifier field contains the identifier for identifying the fault part. The reason for the message issuance is registered in the column, and the Severity of the Trap in the Specific Trap Type field of the SNMP Trap message is registered in the Severity column.
[0048]
FIG. 17 shows a failure log 13700 that the SAN management server 10000 has. In the failure log, the event ID assigned when the SAN manager receives the failure notification message, the time when the failure occurred, the name of the source device of the failure notification message, the failure code in the failure notification message, the ID of the actual mapping including the relevant part, The relationship between the ID of the virtual mapping that includes the part and other fault events is registered
FIG. 18 shows an example of a failure severity conversion table that the SAN management server 10000 has. This conversion table shows the common Severity for failure messages of multiple devices received by the SAN manager and the operations that the SAN manager performs according to the common severity in the failure notification process including the Severity conversion function of the SAN manager described later. To define. This table is defined by the SAN administrator when building the SAN environment. In the failure severity conversion table, a common severity for failure messages of a plurality of devices, a severity of each device corresponding to the common severity, and an operation executed by the SAN manager according to the common severity are registered. For example, in the case of Figure 18, when Severity of storage device A is "3" and Severity of storage device B is "4", "5", or "6", it is regarded as common Severity "3" in the SAN environment. As a result, the SAN manager sends only the failure message information of the storage device A as an SNMP Trap and sends it to the SAN administrator by e-mail. The Severity conversion table is defined based on SAN configuration information. In the Severity conversion table shown in FIG. 18, for example, Severity 3 of storage A and Severity 4 to 5 of storage B are associated as common Severity 3, and only failure information related to storage A is transmitted as an SNMP Trap for the failure notification message of common Severity 3. And is defined to be emailed to the SAN administrator. This is because the storage A virtualizes the real volume that the storage B has and provides it to the server, and the I / O request sent and received by the storage B is sent and received by the server via the storage A. It is defined that the Severity of A and the Severity of storage B are associated with each other, and only failure information related to storage A virtualizing the real volumes of storage A and storage B is output.
[0049]
<SAN Manager virtual volume mapping and real volume mapping creation processing>
Next, virtual volume mapping and real volume mapping creation processing executed by the SAN manager 13100 on the SAN management server 10000 will be described. This processing is periodically executed by the processor 11000 of the SAN management server 10000 executing a program stored in the memory 13000, and creates the latest virtual volume mapping and real volume mapping in the SAN environment, While outputting it, it uses for the fault isolation process and report process which are mentioned later. Hereinafter, unless otherwise specified, each step is performed by the SAN manager 13100.
[0050]
FIG. 19 shows a flowchart 1700 showing an outline of real topology and virtual topology display processing executed by the SAN manager 13100. The SAN manager 13100 detects a device in the SAN based on the device detection list 13500, communicates with the management agent of each device, and copies the information shown in FIGS. 10 to 15 held by each device (step 1710). ). Next, the SAN manager 13100 stores the copied information in the actual topology repository 13400 (step 1720). Thereafter, a virtual volume mapping management table 13300, which will be described later, is created based on the information stored in step 1720 (step 1730). Further, based on the information in the real topology repository 13400 and the virtual volume mapping management table 13300, a real volume mapping management table 13200 described later is created (step 1740). Finally, based on the contents of the virtual volume mapping management table 13300 and the real volume mapping management table 13200, the result such as the actual topology is output (step 1750), and the process ends.
[0051]
FIG. 20 is a flowchart showing detailed processing of the virtual volume mapping management table creation step 1730 executed by the SAN manager 13100. FIG. 8 shows an example of the virtual volume mapping management table 13300 created by the processing shown in FIG.
[0052]
The SAN manager 13100 executes the following processing for all entries in each volume management table for all volume management tables 23300 received from each server and stored in the real topology repository 13400 (step 1810).
[0053]
First, the SAN manager creates a new entry in the virtual volume mapping management table and registers the newly assigned virtual mapping ID 13301. Further, the SAN manager registers the transmission source server name 13302 of the volume management table 23300 currently being processed, and the data I / F ID 13304 and LU ID 13303 stored in the volume management table (step 1820). Next, the SAN manager investigates the data I / F of the switch to which the registered data I / F 13304 is connected, and registers the switch name 13305 and the data I / F ID 13306. Specifically, the SAN manager first uses the data I / F ID 13304 of the server registered in the virtual volume mapping management table 13300 as a key, and receives the data I / F stored in the actual topology repository 13400 from the server. The management table 23200 is searched to check the Port WWN of the data I / F ID. Furthermore, the SAN manager uses the Port WWN as a key to search the FC connection management table 33200 received from the switch A and stored in the actual topology repository 13400, and the server connects to which data I / F of which switch. And the result is registered as a connection destination switch name 13305 and a connection destination switch data I / F ID 13306 (step 1830). Through the above processing, information about the server is registered in the left half (server field) of the virtual volume mapping management table 13300.
[0054]
Next, the SAN manager performs a process for registering information in the left half (storage column) of the virtual volume mapping management table 13300. The SAN manager checks whether the volume registered in the volume management table is provided by the virtualization device from the vendor name and device name registered as volume information in the volume management table 23300. Specifically, the SAN manager searches the device detection list 13500 using the device name as a key, checks whether or not the device has a virtualization function, and if the device has a virtualization function, is provided by the virtualization device. to decide. (Step 1840). Depending on the result of step 1840, processing branches as follows (step 1850).
[0055]
When the volume is provided from a storage device other than the virtualization device, the SAN manager uses the device name and volume ID registered in the volume information column of the volume management table 23300, and the storage name in the storage column of the virtual volume mapping management table 13300. Registered as 13309 and volume ID 13311. Further, the SAN manager searches the real volume management table received from the storage device using the registered volume ID 13311 as a key, investigates the ID of the data I / F used to access the real volume, and stores the result in the storage Registration is made as a data I / F ID 13310 (step 1860). Then, the SAN manager investigates the data I / F of the switch to which the registered storage data I / F 13310 is connected, and registers the switch name and data I / F ID. Specifically, the SAN manager first searches the data I / F management table received from the storage device using the storage data I / F ID 13310 as a key, checks the port WWN of the storage data I / F, and further determines the WWN. As a key, the FC connection management table 33200 received from the switch A is searched, and it is investigated which data I / F of which switch the storage data I / F is connected to. Then, the SAN manager registers the investigation result as a connection destination switch name 13307 and a connection destination switch data I / F ID 13308 (step 1870).
[0056]
If it is determined in step 1850 that the volume is provided from the virtualization device, the SAN manager performs the following processing. First, the SAN manager registers the device name and volume ID registered in the volume information column of the volume management table 23300 in the virtual volume mapping management table 13300 as the storage name 13309 and volume ID 13311. Further, the SAN manager searches the virtual volume management table 43500 and the real volume management table 43300 received from the virtualization device using the registered volume ID 13311 as a key, and the data I / F of the storage device A used to access the volume. And the result is registered as a storage data I / F ID 13310 (step 1861). Next, the switch data I / F corresponding to the data I / F of the storage apparatus A is examined, and the switch name and data I / F ID are registered. Specifically, the SAN manager searches the data I / F management table 33400 received from the switch A using the storage data I / F ID 13310 as a key, and sets the data I / F ID of the switch corresponding to the data I / F. The investigation is performed, and the result is registered as a connection destination switch name 13307 and a connection destination switch data I / F ID 13308 (step 1871).
[0057]
If the volume management table 23300 is not stored in the actual topology repository 13400 because the device is not registered in the device detection list 13500, and if the device does not have a management I / F, in step 1850 the type of device is exceptionally specified. I can't judge. If there is no information registered in the volume information column of the volume management table 23300, the storage column is left blank (step 1862).
[0058]
When the SAN manager executes the above steps for all entries of all volume management tables received from each server by the SAN management server and stored in the real topology repository 13400, the processing of step 1730 ends.
[0059]
FIG. 21 shows a detailed processing flow of the real volume mapping management table creation step 1740 performed by the SAN manager 13100. FIG. 7 shows an example of an actual volume mapping management table created by the processing shown in FIG.
[0060]
The SAN manager 13100 executes the following processing for all entries in the virtual volume mapping management table 13300 created in step 1730 (step 1910).
[0061]
First, the SAN manager creates a new entry and registers the newly assigned real mapping ID 13201 (step 1920). Next, based on the storage name 13309 of each entry in the virtual volume mapping management table 13300, the SAN manager determines whether the device indicated by the storage name has a virtualization function. Specifically, the device detection list 13500 is searched using the storage name 13309 as a key, and the presence / absence of the virtualization function of the device is checked (step 1930).
[0062]
When having a virtualization function, the SAN manager performs the following steps. The SAN manager searches the virtual volume management table 33500 received from the device indicated by the storage name 13309 using the volume ID 13311 in the virtual volume mapping management table entry as a key, and extracts the entry of the virtual volume ID that matches the volume ID 13311 ( Step 1940). Next, the SAN manager prepares the same number of entries as the number of entries obtained by the search in the real volume management mapping table (step 1950). Then, the SAN manager copies the contents of the server column (13302 to 13306) of the entry currently being processed in the virtual volume mapping management table 13300 to the server column (13202 to 13206) for the prepared entry. The contents of the real data I / F ID in the real volume information column of the entry of the virtual volume management table 33500 extracted in step 1940 are copied into the switch data I / F ID column 13208 in the storage column. Further, the storage name and volume ID registered as the real volume information in the real volume information column of the virtual volume management table 43500 are copied to the storage name entry 13209 and the volume ID entry 13211 in the storage column. In the corresponding virtual mapping ID column 13212, the contents of the virtual mapping ID 13301 in the virtual volume mapping management table 13300 are registered. The contents of the switch name 13307 in the storage column of the virtual volume mapping management table are copied to the switch name column 13207 in the storage column (step 1960). Further, the SAN manager searches the real volume management table received from the storage device using the volume ID registered in the volume ID 13211 of the storage column of the real volume mapping management table 13212 as a key, and the data I / The ID of F is searched and registered in the storage data I / F ID 13210 in the storage column of the virtual volume mapping management table.
[0063]
When it is determined in step 1930 that the virtual machine does not have a virtualization function, the SAN manager changes the currently processed entry (13302 to 13311) in the virtual volume mapping management table 13300 to the entry (13202 in the real volume mapping management table 13200). And the contents of the virtual mapping ID 13301 of the virtual volume mapping management table 13300 are registered in the corresponding virtual mapping ID 13212 of the real volume mapping management table 13200.
[0064]
Through the above processing, entries 13201 to 13212 of the real volume mapping management table 13200 are registered.
[0065]
When the SAN manager has executed the above steps for all entries in the virtual volume mapping management table 13300, the processing shown in step 1740 ends.
[0066]
FIG. 23 shows an example of the actual topology display output from the SAN manager 13100 to the output unit 15000 based on the actual volume mapping table shown in FIG. An output example showing the connection relationship among servers, switches, and storages based on the contents of the real volume mapping management table 13200 is the real topology display 2010.
[0067]
<SAN manager failure isolation process>
An example of fault isolation processing by the SAN manager is shown below.
[0068]
The fault monitoring function by the current SAN management software often uses an SNMP protocol Trap message defined by RFC 1157 “A Simple Network Management Protocol (SNMP)” created by the Internet Engineering Task Force (IETF). However, since the volume allocated to the server by the virtual volume technology is virtualized, it is difficult to identify the fault location at the virtual volume level. Also, SAN administrators rely on manual operations by SAN administrators who have advanced knowledge of individual devices to isolate faults based on events issued from multiple devices. Very expensive.
[0069]
Therefore, in this process, the SAN manager that has received the failure notification issued by multiple devices, based on the failure analysis dictionary and the SAN configuration information obtained from each management agent and stored in the actual topology repository, Analyzes the impact of I / O on I / O access to real and virtual volumes. Further, it analyzes whether there is a failure message related to the failure message among failure messages received during a certain period before receiving the failure message, and examines the relationship between the failure messages. Then, these results are output by the SAN manager, thereby reducing the analysis of multiple failure messages and the failure identification work by the SAN administrator.
[0070]
Before explaining the fault isolation process, Fig. 25 shows the format of the SNMP Trap message received from each device in the SAN by the SAN manager on the SAN management server 10000, and an example of the SNMP Trap message. deep. Here, the SNMP Trap message is a failure notification message transmitted from the management agent of each device in the SAN to the SAN management server 10000. FIG. 25 (a) illustrates the format of the SNMP Trap message. SNMP message, message header, message destination community name, PDU (Protocol Data Unit) Type indicating the message type, Enterprise indicating the vendor name of the source device, Agent Address indicating the destination IP address, It consists of Generic Trap Type indicating the type of Trap message, Specific Trap Type indicating the Severity of Trap message, Timestamp indicating the transmission time of the message, and Variable Bindings fields for storing the message contents. When the value of the PDU Type field is “4”, the message is identified as an SNMP Trap message. When the value of the Generic Trap Type field is "6", the SNMP Trap message is identified as a Trap message based on the definition unique to the transmission source device vendor, and the Severity described in the Specific Trap Type field defined by each vendor It is necessary to interpret the Trap message based on the contents of the fault code described in the Variable Bindings field.
[0071]
FIG. 25 (b) shows an example of an SNMP Trap message transmitted from the storage A 40000 to notify the hardware failure of its own device in this embodiment. The message shown in FIG. 25 (b) is recognized as an SNMP Trap message because the PDU Type is “4”, and the Trap message based on the definition unique to the transmission source vendor because the Generic Trap Type is “6”. It is recognized that Further, it is assumed that the vendor defines that the Specific Trap Type field stores a failure severity, and the Variable Bindings field stores a failure code indicating a failure occurrence site. Therefore, the SNMP Trap message shown in FIG. 25 (b) represents that a failure with a failure code “30c1” has occurred with a severity of “1”.
[0072]
FIG. 22 shows a flowchart 2400 showing an example of a fault isolation process performed by the SAN manager 13100 on the SAN management server 10000. Hereinafter, unless otherwise specified, each step is performed by the SAN manager 13100.
[0073]
The SAN manager 13100 waits until an SNMP Trap message is received from a certain device (step 2410). Upon receipt of the message, the SAN manager extracts the IP address of the device that issued the message from the Agent Address field of the message (step 2415), and the device detection list stored in the actual topology repository 13400 using the extracted IP address as a key. Search for 13500 (step 2420).
[0074]
If the IP address does not exist in the device detection list 13500, the SAN manager cannot analyze the contents of the Trap message because it is a Trap message from an unregistered device. Therefore, the SAN manager creates a new entry in the failure log 13700, assigns an event ID, outputs the IP address as the failed device, outputs the Trap message itself as the failed part (step 2465), and jumps to the processing of step 2455 described later.
[0075]
In step 2420, if the extracted IP address exists in the device detection list 13500 and the device that issued the Trap message can be identified, the SAN manager checks whether the SAN management server 10000 has a failure analysis dictionary for the device. (Step 2425).
[0076]
If a failure analysis dictionary is provided in step 2425, the SAN manager creates a new entry in the failure log 13700, assigns an event ID, extracts the failure occurrence time from the message Timestamp field, and registers it in the time column. Furthermore, the device name is registered. Further, the failure analysis dictionary is searched using the Variable Bindings field of the Trap message as a key. If a failure code is registered, the failure code is registered in the failure code column (step 2430).
[0077]
If it is determined in step 2425 that the failure analysis dictionary is not provided, the SAN manager creates a new entry in the failure log 13700, assigns an event ID, extracts the failure occurrence time from the message Timestamp field, and enters the time column. Register as well as the device name. Further, the SAN manager regards the failure part as the whole device, registers it as “whole device” in the failure code column, and continues the subsequent steps (step 2431).
[0078]
After step 2430 or step 2431 is completed, the SAN manager investigates whether or not the failure part indicated by the registered failure code is related to real volume mapping and virtual volume mapping (step 2435). Specifically, first, the failure part and its identifier are searched for the entry of the failure analysis dictionary of the registered failure device name using the failure code as a key. Next, a search is made for a matching entry in the real volume mapping management table 13200 using the faulty device name and the faulty part or faulty part identifier obtained previously as keys. If there is a matching entry, the SAN manager extracts the real mapping ID 13201 and virtual mapping ID 13212 from the entry, and registers them in the real volume column and virtual volume column of the entry being created in the failure log 13700.
[0079]
Thereafter, the SAN manager investigates whether the identified failure part is related to virtual volume management (step 2440). Specifically, the virtual volume management table 43500 is searched for a matching entry by using the faulty device name searched in step 2435 and the faulty part or faulty part identifier as keys. If there is a matching entry, the SAN manager extracts the virtual volume ID from the entry. Further, using the extracted virtual volume ID as a key, a search is made for a matching entry in the real volume mapping management table 13200, the real mapping ID 13201 and the virtual mapping ID 13212 are extracted, the real volume column of the entry being created in the fault log 13700, the virtual Register in the volume column.
[0080]
In step 2435 and step 2440, after registering the relationship between the real volume mapping and virtual volume mapping of the failure log creation entry, the SAN manager investigates the relationship between the creation entry and another failure log entry. First, the SAN manager investigates whether the entry being created is due to a hardware failure or an access error to another part (step 2445). Specifically, the cause of the failure analysis dictionary entry of the registered failure device name is searched for using the failure code as a key.
[0081]
If the cause investigated in step 2445 is a hardware failure, it is determined that the event being created is a “parent event” that may trigger another failure event, and “parent event” is displayed in the event relation column. Register (step 2450). If the cause investigated in step 2445 is due to an access error to another part, it is determined that the event being created is a “child event” that may have been issued due to another failure event. Then, “child event” is registered in the event relation column (step 2451).
[0082]
Finally, the SAN manager outputs the contents of the created failure log entry as a failure message (step 2455). Thus, the flowchart 2400 is completed.
[0083]
Here, a specific example of the fault isolation process of the SAN manager 10000 shown in the flowchart 2400 will be described. FIG. 23 is a diagram illustrating an example of how the failure log entry illustrated in FIG. 17 is output by the failure isolation process illustrated in the flowchart 2400. Here, event IDs 1000, 1001, 1002, and 1003 are four failure messages generated by a hardware failure in the data I / F ID d1 of the storage apparatus B. Thus, the following describes how the four failure messages are analyzed and related.
[0084]
When the failure message of event ID 1000 is received, the SAN manager analyzes a hardware failure of the data I / F ID d1 of the storage apparatus B in step 2430. Further, in step 2435, it can be seen that the actual volume mapping pm2 and the virtual volume mapping vm2 are related. Further, step 2445 reveals that the hardware failure is a “parent event”.
[0085]
Next, when the failure message of event ID 1001 is received, the SAN manager analyzes that an access error has occurred when expanding the I / O of the virtual volume vv1 of the storage device A to the real volume vb1 in step 2430. Further, in step 2435, it can be seen that the actual volume mapping pm2 and the virtual volume mapping vm2 are related. Further, step 2445 reveals that the access error is a “child event”. Similarly, it can be seen that the failure message with event ID 1002 and the failure message with event ID 1003 are also “child events”.
[0086]
When outputting a failure message in step 2455, the SAN manager investigates the real volume column, virtual volume column, and event relationship column of the failure message issued within a certain period of time, and whether there is a relationship between each failure message or not. In this case, specify either "parent event" or "child event". Here, the “certain time” is a time specified in advance by the SAN administrator and serving as a unit of fault association. The event IDs 1000, 1001, 1002, and 1003 in FIG. 17 are all associated with the real volume mapping pm2 and the virtual volume mapping vm2, and the event ID 1000 is a “parent event”. In the event list window 2020, for example, the association can be shown in the event relevance column like a symbol 2021.
[0087]
For example, when the SAN administrator designates a specific failure event such as event designation 2022, the SAN manager 10000 displays an event designated as real topology mapping display 2011 in the real topology display window 2010. The actual topology mapping corresponding to may be illustrated. Further, the content of the designated event may be displayed in an easy-to-understand manner as in the failure notification window 2012.
[0088]
As described above, when a SAN manager receives fault messages from multiple devices that make up the SAN through fault isolation processing, the SAN manager automates the analysis of the fault messages and the association with other fault messages. Can reduce the burden of carving
<Failure report processing including Severity conversion function of SAN manager>
An example of failure notification processing including the severity conversion function by the SAN manager is shown below. In this process, the SAN manager holds the Severity conversion function of multiple storage devices connected to the virtualization device. When a failure message is received according to the failure severity conversion table definition predefined by the SAN administrator, the conversion is performed. In accordance with the common severity defined in the table, reports to the upper management program and reports to the administrator are implemented.
[0089]
FIG. 24 shows a flowchart 2500 of failure isolation processing performed by the SAN manager 13100 on the SAN management server 10000. Hereinafter, unless otherwise specified, each step is performed by the SAN manager 13100.
[0090]
The SAN manager 13100 waits until an SNMP Trap message is received from a certain device (step 2510). When receiving the message, the SAN manager extracts the IP address of the device that issued the message from the Agent Address field of the message (step 2515).
[0091]
Based on the extracted IP address, the SAN manager investigates whether the message issuing device is related to the common severity definition (step 2520). In particular,
First, by checking whether or not the extracted IP address exists in the device detection list 13500, the device that issued the message is specified. Next, it is investigated whether or not the Severity column relating to the identified device exists in the failure severity conversion table 13800.
[0092]
If it is determined in step 2520 that the message issuing device is not related to the common severity definition, the SAN manager does not perform the severity conversion function and transfers the trap message as it is to the upper management software (step 2526).
[0093]
If it is determined in step 2520 that the message issuer device is related to the common severity definition, the message issuer device severity is extracted from the specific trap type field of the SNMP Trap message (step 2525). Based on the device name of the message issuer and the extracted Severity, the failure severity conversion table 13800 is examined to identify the common severity and action (step 2530). Finally, the action specified in step 2530 is executed (step 2535). Thus, the flowchart 2500 is completed.
[0094]
Here, a specific example of the failure notification process of the SAN manager 10000 shown in the flowchart 2500 will be described. Consider a case where an event with event ID 2000 is received among the entries in the failure log shown in FIG. The failure message of event ID 2000 is determined in step 2515 that the storage apparatus B is the issuing source apparatus, and is therefore determined in step 2520 as being related to the common severity definition. Since the Severity in the Trap message is “4” in Step 2525, the action “Trap transmission and email transmission of storage A information” described in the failure Severity conversion table 13800 is applied. Not reported to management software and SAN administrator.
[0095]
As described above, the SAN manager defines unified Severity in the failure messages of multiple storage devices received by the SAN manager through notification processing including the severity conversion function, and provides the failure notification function of the SAN manager according to the definition. be able to.
[0096]
Note that the storage manager's actual topology mapping and virtual topology mapping creation processing, failure isolation processing, and failure notification processing including Severity conversion function assumed that the storage device A 40000 is a virtualization device. Even in a configuration in which a device different from the storage device A40000 is connected to the management network 70000 and the SAN 60000 as a virtualization device, the above-described processing can be similarly realized.
[0097]
According to the embodiment described above, when a device in which the SAN manager is executed receives a failure message from a plurality of devices constituting the SAN in the SAN having the virtualization device, the SAN manager analyzes the failure message. And automating the association with other failure messages, reducing the burden of SAN administrators on fault isolation.
[0098]
In addition, by defining a unified Severity in the failure messages of multiple storage devices received by the SAN manager in the SAN, the SAN manager and higher system management software can report the failure using a method according to the definition. However, only necessary and sufficient failure information is received, and it becomes possible to speed up failure countermeasures after reporting.
[0099]
【The invention's effect】
According to the present invention, when a failure message is issued from a device connected to the SAN, it is possible to support the failure identification by the SAN administrator.
[0100]
Further, in the SAN, the SAN administrator and the upper system management software can receive necessary failure information among failure messages issued from devices existing in the SAN.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating a configuration example of a SAN.
FIG. 2 is a diagram illustrating a configuration example of a SAN management server.
FIG. 3 is a diagram illustrating a configuration example of a server.
FIG. 4 is a diagram illustrating a configuration example of a switch.
FIG. 5 is a diagram illustrating a configuration example of a storage apparatus having a virtualization function.
FIG. 6 is a diagram illustrating a configuration example of a storage apparatus.
FIG. 7 is a diagram showing an example of an actual volume mapping management table held by a SAN management server.
FIG. 8 is a diagram showing an example of a virtual volume mapping management table held by a SAN management server.
FIG. 9 is a diagram illustrating an example of a device detection list held by a SAN management server.
FIG. 10 is a diagram illustrating an example of a data I / F management table held by a server.
FIG. 11 is a diagram showing an example of a volume management table held by a server.
FIG. 12 is a diagram illustrating an example of an FC connection management table held by a switch.
FIG. 13 is a diagram showing an example of a data I / F management table held by the storage apparatus.
FIG. 14 is a diagram showing an example of a real volume management table held by the storage apparatus.
FIG. 15 is a diagram showing an example of a virtual volume management table held by the storage apparatus.
FIG. 16 is a diagram showing an example of a failure analysis dictionary table related to storage devices held by the SAN management server.
FIG. 17 is a diagram illustrating an example of a failure log held by a SAN management server.
FIG. 18 is a diagram showing an example of a failure severity conversion table held by the SAN management server.
FIG. 19 is a flowchart illustrating an example of storage network real topology mapping and virtual topology mapping creation processing performed by the SAN management server;
FIG. 20 is a flowchart illustrating an example of detailed processing contents of a virtual volume mapping management table creation step performed by the SAN management server.
FIG. 21 is a flowchart showing an example of detailed processing contents of a real volume mapping management table creation step performed by the SAN management server.
FIG. 22 is a flowchart illustrating an example of failure isolation processing performed by a SAN management server.
FIG. 23 is a diagram illustrating an example of a fault isolation result display output by the SAN management server.
FIG. 24 is a flowchart illustrating an example of a failure notification process including a severity conversion function performed by the SAN management server.
FIG. 25 is a diagram illustrating a configuration example of an SNMP Trap message.
FIG. 26 is a diagram illustrating a configuration example of a SAN.
FIG. 27 is a diagram illustrating a configuration example of a SAN.
[Explanation of symbols]
10000: SAN management server
13100: SAN manager
20000: Server
30000: Switch
40000: Storage device A
50000: Storage device B
23100: Server management agent
33100: Switch management agent
43100: Management agent for storage device A
53100: Management agent for storage device B
47000: Real volume provided by storage device A
48000: Virtual volume provided by storage device A
57000: Real volume provided by storage device B

Claims (16)

One or more storage devices each having a real volume;
A virtualization device is connected to the one or more storage devices via a first network, which constitutes the real volume of the one or more storage devices as a virtual volume is provided to the host device,
A failure information management method in a system having a management server connected to the one or more storage devices and the virtualization device via a second network,
A first failure detection step in which the one or more storage devices detect failures for a plurality of real volumes;
A second failure detection step in which the virtualization device detects failures for a plurality of virtual volumes ;
The management server receives a failure notification for the plurality of real volumes detected by the first failure detection step or a failure notification for the plurality of virtual volumes detected by the second failure detection step. A fault notification receiving step;
Based on a volume management table indicating correspondence information indicating which real volume the virtual volume managed by the virtualization device is configured to , the management server handles each of the plurality of real volumes notified of the failure. to identify the virtual volume, when receiving the failure notification for a particular virtual volume, the steps associated with a failure notification for said virtual volume the to associate a failure notification for real volume,
A failure notification for the virtual volume, a failure notification for the real volume, and a failure notification output step for outputting information indicating that the failure notification for the virtual volume is associated with the failure notification for the real volume. Fault information management method characterized by the above. The failure information management method according to claim 1,
In the association step , out of a plurality of failure notifications received by the management server within a predetermined period, a failure notification for the plurality of real volumes notified of the failure, and a virtual volume corresponding to each of the plurality of real volumes A failure information management method comprising: associating a failure notification with respect to a failure notification as a related failure notification . The failure information management method according to claim 1,
Further, the management server, receiving configuration information of the first network from the device connected to the first network,
A failure information management method comprising: a step of specifying a correspondence relationship between the identification information of the real volume and the identification information of the virtual volume based on the configuration information. The failure information management method according to claim 1,
The associating step further includes a failure factor specifying step of specifying a cause of failure for each failure notification for the failure notification for the associated virtual volume and the failure notification for the real volume based on the volume management table. Have
In the failure notification output step , the failure information about the virtual volume and the failure notification for the real volume are output together with the cause specified in the failure factor specifying step . The failure information management method according to claim 4,
Corresponding to the real volume due to the cause of failure in the failure notification for the real volume among the failure notification for the associated virtual volume and the failure notification for the real volume in the failure factor specifying step A failure information management method characterized by specifying that a failure notification indicating that a failure has occurred in a virtual volume is issued. The failure information management method according to claim 4,
Of the failure notification for the associated virtual volume and the failure notification for the real volume in the failure factor identification step , the failure notification for the real volume or virtual volume notified by a hardware failure, and the hardware A failure information management method characterized by identifying a failure notification for a real volume or a virtual volume notified by an access error caused by an influence of a failure. The failure information management method according to claim 1,
Further, a plurality of pieces of importance information representing importance of failure notifications based on different criteria included in the plurality of failure notifications received from the one or more storage devices and the virtualization device are stored in the one or more storage devices. And the management server converts to importance information based on common criteria in a system including the virtualization device ,
A failure information management method, wherein in the failure notification output step, the management server outputs a failure notification by a predetermined method based on the importance information after conversion. The failure information management method according to claim 1,
The system further includes a switch for interconnecting the one or more storage devices, the virtualization device, and the management server,
The failure detection step includes a step of detecting a failure of the switch,
In the failure notification receiving step , the management server further receives a failure notification from the switch ,
In the association step , a failure notification for the virtual volume in the virtualization device, a failure notification for the real volume in the one or more storage devices connected via the switch, and a failure from the switch Determining whether the notification is relevant, specifying that a failure notification for a virtual volume corresponding to the real volume and a failure notification from the switch are issued due to a failure in the failure notification for a certain real volume ,
In the failure notification output step , the failure notification for the real volume is a first failure notification, the failure notification for the virtual volume and the failure notification for the switch are a second failure notification , fault information management method, wherein a failure notification outputs information indicating that associated with the first fault notification. One or more storage devices each having a real volume and the one or more storage devices connected via a first network, and configuring the real volume of the one or more storage devices as a virtual volume, A management server connected via a second network to the virtualization device provided to
An interface controller for connecting to the second network;
A processor;
A memory storing a program executed by the processor and information used by the processor;
An output unit for outputting a processing result of processing executed by the processor;
The interface control unit receives a failure notification for a plurality of real volumes from the one or a plurality of storage devices, receives a failure notification for a plurality of virtual volumes from the virtualization device,
The processor responds to each of the plurality of real volumes notified of a failure based on a volume management table indicating correspondence information indicating which of the real volumes the virtual volume managed by the virtualization apparatus is configured with. When the virtual volume is specified and the failure notification for the specified virtual volume is received, the failure notification for the virtual volume is associated with the failure notification for the real volume,
The output unit outputs information indicating that the processor is associated with a failure notification for the virtual volume, a failure notification for the real volume, and a failure notification for the virtual volume and a failure notification for the real volume. A management server characterized by: The management server according to claim 9,
The processor includes a failure notification for the plurality of real volumes notified of the failure from a plurality of failure notifications received by the interface control unit within a predetermined period, and a virtual volume corresponding to each of the plurality of real volumes. A management server characterized by associating a failure notification with respect to a failure notification as related. The management server according to claim 9,
The interface control unit receives configuration information of the first network from the device connected to the first network,
The management server, wherein the processor specifies a correspondence relationship between the identification information of the real volume and the identification information of the virtual volume based on the configuration information. The management server according to claim 9,
The processor specifies the cause of failure for each failure notification for the failure notification for the associated virtual volume and the failure notification for the real volume based on the volume management table,
The output unit outputs the specified cause together with a failure notification for the virtual volume and a failure notification for the real volume . In the management server according to claim 12,
The processor of the failure notification for failure notification for associated said virtual volume and the real volume, due to the cause of the failure notification failure for the real volume, the virtual volume corresponding to the real volume A management server that specifies that a failure notification indicating that a failure has occurred is issued. In the management server according to claim 12,
The processor includes a failure notification for a real volume or a virtual volume notified by a hardware failure, and a failure notification for the hardware failure among a failure notification for the associated virtual volume and a failure notification for the real volume. A management server that identifies a failure notification for a real volume or a virtual volume that is notified by an access error caused by the influence. The management server according to claim 9,
The processor further includes a plurality of pieces of importance information representing importance of failure notifications based on different criteria included in the plurality of failure notifications received from the one or more storage devices and the virtualization device. Conversion into importance information based on common criteria in the system including the storage device and the virtualization device,
The output server outputs a failure notification by a predetermined method based on the importance information after conversion. The management server according to claim 9,
The management server is connected to the one or more storage devices and the virtualization device via a switch,
The interface control unit receives a failure notification from the switch,
The processor relates to a failure notification for a virtual volume in the virtualization device, a failure notification for a real volume in the one or more storage devices connected via the switch, and a failure notification from the switch. To decide,
Specifying that a failure notification for a virtual volume corresponding to the real volume and a failure notification from the switch are issued due to a failure in a failure notification for a real volume,
The output unit uses the failure notification for the real volume as a first failure notification, the failure notification for the virtual volume and the failure notification for the switch as a second failure notification, and the second failure notification is A management server that outputs information indicating that it is associated with the first failure notification.

Images