Storage apparatus and failover method

A storage apparatus is provided with a virtualization mechanism which manages first and second LPARs (logical partitions) assigned respectively with first and second logical resources acquired by logically partitioning physical resources in the storage apparatus. The virtualization mechanism provides a shared memory area which is an area based on a memory and can be accessed by the first and second LPARs. The first LPAR stores information required for taking over a data input/output process handled by the first LPAR to the second LPAR, in the shared memory area. When detecting that a fault occurs in the first LPAR, the second LPAR acquires the information required for taking over from the shared memory area and takes over and executes the data input/output process formerly handled by the first LPAR on the basis of the information required for taking over.

TECHNICAL FIELD

The present invention relates to a failover among a plurality of logical partitions (LPARs).

BACKGROUND ART

An element that configures a network is generally known as a node, and a cluster into which a plurality of nodes (for example, server machines) are interconnected is known. Here, the cluster indicates a system that behaves as if it is overall a single node (apparatus) in regard to an external apparatus. Generally, if any one node within a cluster develops a fault, a failover is executed, in which another node takes over its processing and data.

A known technology for use even when failovers occur includes, for example, a technology of matching transactions, while at the same time limiting deterioration in disk I/O performance (see, for example, PTL 1). Additionally, a technology that enables the replacement of individual LPARs by configuring a replacement destination LPAR on another physical computer if a fault has occurred in an LPAR on a physical computer is also known (see, for example, PTL 2).

CITATION LIST

Patent Literature

SUMMARY OF INVENTION

Technical Problem

In a storage apparatus capable of executing a plurality of LPARs, it is preferable to fail over swiftly to another LPAR when a fault has occurred in any one LPAR.

Solution to Problem

The storage apparatus is provided with a virtualization mechanism configured to manage first and second LPARs (logical partitions) assigned respectively with first and second logical resources acquired by logically partitioning physical resources in the storage apparatus. The virtualization mechanism provides a shared memory area which is an area based on a memory and can be accessed by the first and second LPARs. The first LPAR stores information required for taking over a data input/output process handled by the first LPAR to the second LPAR, in the shared memory area. When detecting that a fault occurs in the first LPAR, the second LPAR acquires the information required for taking over from the shared memory area and takes over and executes the data input/output process formerly handled by the first LPAR on the basis of the information required for taking over.

Advantageous Effects of Invention

The present invention makes possible the swift execution of a failover between LPARs.

DESCRIPTION OF EMBODIMENTS

The following describes one embodiment in reference to the drawings.

In the following description, expressions such as “aaa table” are in some cases used to describe information, but this information may be expressed in formats other than tables or other data structures. In order indicate that such information is not dependent on data structures, “aaa table”, etc., may be referred to as “aaa information”.

Additionally, in the following description, processes in which the “program” is the subject are described in some cases, but since the program is operated by a processor (for example, a CPU (Central Processing Unit)), and the specified processes are executed using an appropriate storage resource (for example, memory) and/or communications interface, the subject of the process may equally be the “processor”. Additionally, the processor may include a hardware circuit that implements part or all of the process. The computer program may be installed from the program source to the computer. The program source may, for example, be a program distribution server or a computer-readable storage media.

Furthermore, in some cases in the following description, where like elements are described without differentiation, reference symbols are used, and where like elements are described with differentiation, in place of the reference symbols, the elements are assigned identification numbers.

In addition to this, the meanings of terms used in the following description are as follows:(*) “LPAR” is the abbreviation for logical partition (Logical Partition), which is a virtual machine to which a logical resource, acquired by logically partitioning physical resources, has been assigned. The LPAR is recognized as a single piece of apparatus by an external apparatus (for example, the client).(*) “Hypervisor” is a type of virtualization mechanism that creates and operates LPARs.(*) “Node” means an element that configures a network. In the present embodiment, the node is the LPAR which is the cluster configuration element.(*) “Cluster” is a system configured from a plurality of nodes, which behaves as if it is overall a single node (apparatus) in regard to an external apparatus (for example, a client).(*) “Failover” means a second apparatus taking over processes and data in the case of a fault occurring in a first apparatus, or the function thereof. The first apparatus and second apparatus may, respectively, be either physical or logical apparatus. In the present embodiment, both the first and second apparatus are LPARs.

Firstly, in reference toFIG. 20, an outline of a computer system relating to an embodiment is described.

The computer system is provided with a converged platform apparatus10which is one example of a storage apparatus and is coupled to a client80. A plurality of LPARs50created by a hypervisor60, operate on the converged platform apparatus10. The hypervisor60manages a plurality of logical resources acquired by logically partitioning physical resources including a memory, and the LPARs to which each of the plurality of logical resources is assigned. The LPARs50include LPARs1and2. Logically partitioning the memory provides a memory area1, a memory area2, and a shared memory area212as a logical resource. The memory area1is assigned to the LPAR1, and the memory area2is assigned to the LPAR2. Furthermore, a shared memory area which can be accessed by both of the LPARs1and2, is assigned to the LPARs1and2.

The LPAR1stores information required for taking over, required for the LPAR2to take over the operation of the LPAR1, in the shared memory area212

(FIG.20(1)). Here, the information required for taking over comprises, for example, information relating to the resource group for the LPAR1, configuration information for the file system, and information relating to file locks in the file system (lock information). The LPAR1reflects the lock information for the file that is the subject of the access request in takeover information in the shared memory area212(FIG.20(3)) in cases where receiving an access request for a file from the client80(FIG.20(2)). If the LPAR2recognizes that a fault has occurred in the LPAR1, the LPAR2acquires the information required for taking over from the shared memory area212, and implements the various configurations, etc., on the basis of the information required for taking over. In this way, the LPAR2takes over and executes the processes of the LPAR1. According to the present embodiment, since, in this way, information required for taking over can be acquired from the shared memory area212, a swift failover is possible if a fault has occurred in the LPAR1.

The following is a detailed description of the embodiment.

FIG. 1is a configuration diagram of the computer system.

The computer system is provided with a plurality of (or single) client(s)80and the converged platform apparatus10to which the plurality of clients80are coupled. The client80and the converged platform apparatus10are coupled by a communications network such as a TCP/IP network.

The client80is one example of a host apparatus, and is a computer that executes data access (read/write) for individual files in the converged platform apparatus10. Specifically, the client80issues a file access request (file read request or write request) to the converged platform apparatus10.

The client80is provided with a memory81, a NIC (Network Interface card)83, a physical storage device (hereinafter, PDEV)84, and a CPU82to which the memory81, the NIC83, and the PDEV84are coupled. The memory81stores the programs and data used by the CPU82. The CPU82executes the various processes by running the programs stored in the memory81. The NIC83is one example of a communications interface device used in coupling to another apparatus (for example, the converged platform apparatus10). The PDEV84is a non-volatile storage device such as an HDD (Hard Disk Drive) or SSD (Solid State Drive). The PDEV84may store programs, etc., used to control the client80, such as the OS (Operating System) executed by the CPU82.

The converged platform apparatus10is provided with a server part20and a storage part11. The server part20and the storage part11are coupled through an internal data bus (for example, PCIe bus)40.

The server part20may be a circuit base board (for example, a blade server). The server part20is provided with a memory21, a NIC23, an internal I/F24, and a CPU22to which the memory21, the NIC23, and the internal I/F24are coupled. The memory21may, for example, be DRAM (Dynamic Random Access Memory), which stores the various programs and data executed by the CPU22. The CPU22executes the various processes by running various programs stored in the memory21. The NIC23is an example of a communications interface device used in coupling with another apparatus (for example, the client80). The server part20runs one or a plurality of OSs, provides file server functions, and executes applications. The internal I/F24is one example of a communications interface device used to communicate via the internal data bus40. The server part20receives a file access request from the client80, and sends, to the storage part11, a block I/O request (I/O request for the data block to configure the file to be accessed) based on this access request.

The storage part11is provided with a plurality of PDEVs31, and a RAID (Redundant Array of Independent (or Inexpensive) Disks) control part30which is coupled to the plurality of PDEVs31. A RAID group may also be configured from two or more PDEVs31. An LU (Logical Unit) is configured on the basis of the RAID group. The RAID control part30is the module that controls access to the PDEV31(for example, a circuit board), and may be provided with a communications interface device, for the purpose of communicating via the internal data bus40, a memory, and a CPU to which the interface device, the data bus40, and the memory are coupled. The RAID control part30receives a block level I/O request from the server part20and executes the I/O process (read process/write process) in regard to the PDEV31, in line with the I/O request.

FIG. 2is a configuration diagram of the computer system, including the software.

The converged platform apparatus10is coupled to a management computer90, in addition to the client80. The management computer90is the computer used by the administrator of the computer system to manage the computer system, which may, for example, receive various indications from the administrator and transmit them to the converged platform apparatus10.

The hypervisor60on the memory21is executed by the CPU22in the converged platform apparatus10. The hypervisor60manages the logical resources acquired by logically partitioning the physical resources of the converged platform apparatus10(the memory21, the CPU22, and the NIC23, etc.). The hypervisor60creates the LPAR50to which the logical resource is assigned. The OS may be operated by each LPAR50. The hypervisor60creates the memory area1for use by the LPAR1, the memory area2for use by the LPAR2, and the shared memory area212for the LPARs1and2, by logically partitioning the memory21. A cluster configuration management table100(seeFIG. 3), a takeover information management table110(seeFIG. 4), and a fault monitoring management table130(seeFIG. 5), described below, may, for example, be managed in the shared memory area212.

Logically partitioning the CPU22provides a CPU1and a CPU2as logical resources. The CPU1is the CPU for the LPAR1(the logical resource assigned to the LPAR1), and the CPU2is the CPU for the LPAR2.

The LPAR50operates a file sharing program51, a file system52, a failover program53, and a kernel/driver54.

The file sharing program51uses a communications protocol such as a CIFS (Common Internet File System) or an NFS (Network File System) to provide a file sharing service that allows file sharing among a plurality of clients.

The file system52includes a logical structure configured to realize management units known as files on an LU311. In the present embodiment, the file system52includes a file system program to manage the logical structure. The file system52includes, as its logical structure, a superblock, an Mode management table, and data blocks. The superblock, mode management table, and data block are well known and as such only a brief description is given herein. The superblock holds the overall file system information. For example, the superblock holds management information for the file system as a whole, including the size of the file system, the free space within the file system, etc. The Mode management table manages metainformation for individual files/directories. The Mode management table also manages the addresses of files in the data block. Note that the structure of the file system52is stored in the LU311, and part or all of the structure is called to the LPAR memory area.

The failover program53monitors faults occurring in other LPARs50in the same cluster, and when it detects a fault, it takes over the resources (IP address, file system, etc.) operating on the LPAR50where the fault originated, and implements a failover that reopens the file sharing service that was being run by the LPAR50where the fault originated.

The kernel/driver54is a program that provides overall control, for example, controlling the schedule of a plurality of programs (processes) being operated on the converged platform apparatus10, and handling interruptions from hardware, as well as control unique to the hardware.

The RAID control part30executes the input/output process in regard to the LU311based on the RAID group.

As shown inFIG. 2, the program executed by LAPR n (where n=1 or 2) and the logical resource assigned to the LPAR n are assigned the same number as the LPAR. In order to avoid overly lengthy description, hereinafter, the number n is, in some cases, used in place of the reference symbol to refer to a program executed by the LPAR n or a logical resource assigned to the LPAR n.

FIG. 3is a configuration diagram of one example of the cluster configuration management table.

The cluster configuration management table100contains fields for a counterpart node name100a, a monitoring interval100b, a number of resource groups100c, and a resource group100d.

The name of the counterpart node (LPAR) that makes up the cluster configuration is stored under the counterpart node name100a.The time interval for implementation of fault monitoring is stored under the monitoring interval100b.The number of resource groups into which the resources required to provide the LPAR file sharing service are divided is stored under the number of resource groups100c.The number of resource groups100dis equal to or greater than the number configured in the number of resource groups100c.Information relating to the resource group (resource group information), for example, the IP address used to access the resource group by the client80, the number of file systems attached to the resource group, and the name of each of the file systems attached to the resource group are stored under the resource group100d.

FIG. 4is a configuration diagram of one example of the takeover information management table.

The takeover information management table110contains fields for NFS configuration information110a, CIFS configuration information110b, and lock information110c.

The IP address at which information is published, the name of the published directory, and the right to access are stored in the NFS configuration information110aand the CIFS configuration information110b, respectively. The IP address at which the information is published is the IP address of the computer (client, etc.) publishing the file system. The name of the published directory is the name of the directory being published. The published directory may be a directory within the file system, the root directory of the file system, or the root directory of the global namespace. The right to access indicates the type of access permitted to the site on which the information is published. Types of the right to access include read-only permission and read/write permission, etc.

The file name and IP address are stored in the lock information110c. The file name is the name of the file being locked. The IP address is the IP address of the computer locking the file with the file name (the lock owner).

In the description of the present embodiment, all the information stored in the cluster configuration management table100is at times referred to as “cluster configuration information”, and all the information stored in the takeover information management table110is at times referred to as “takeover information”. The information configured in the cluster configuration management table100and the takeover information management table110are one example of the information required for taking over.

FIG. 5is a configuration diagram of one example of the fault monitoring management table.

A fault monitoring management table120contains fields for a counter1120a, a counter2120b, and a fault flag120c.The count value counted up by the LPAR1is stored under the counter1120a.The count value counted up by the LPAR2is stored under the counter2120b.The count value may be updated using a separate method, for example, counting down instead of counting up. The count value is one example of confirmation information. The flag (fault flag) that indicates whether or not a fault has occurred in the LPAR is stored under the fault flag120c.The fault flag is configured to come ON when the hypervisor60detects a fault in the LPAR.

The following is a description of the process implemented in the present embodiment.

Firstly, an initial process is described in reference toFIG. 6andFIG. 11.

FIG. 6is a pattern diagram of the initial process, whileFIG. 11is a flow chart depicting the initial process.

The management computer90sends the received cluster configuration information and takeover information to the LPAR1on the converged platform apparatus10(FIG.6(2)) when receiving the input of cluster configuration information and takeover information in regard to the LPAR1from the administrator, and receives a cluster configuration request indication (FIG.6(1)).

A failover program1of the LPAR1receives the cluster configuration information and the takeover information from the management computer90(FIG.11(S11)), and requests the retention of a shared memory area from the kernel/driver54(FIG.11(S12), FIG.6(3)). The kernel/driver54requests the retention of a shared memory area from the hypervisor60(FIG.6(4)). On receiving a request for the retention of a shared memory area, the hypervisor60retains the shared memory area212from the memory21(FIG.6(5)).

Once the shared memory area212has been retained, the failover program1registers cluster configuration information, in the form of the cluster configuration management table100, to the shared memory area212via a kernel/driver1((FIG.11(S13), FIG.6(6)), and registers takeover information, in the form of the takeover information management table110, to the shared memory area212(FIG.11(S14), FIG.6(6)). At least one of part of the cluster configuration information and part of the takeover information may also be stored on at least one of the LUs311, either instead of or in addition to the shared memory area212.

Next, there follows a description of a regular process which is one of the processes that takes place after the initial process, in reference toFIG. 7,FIG. 12andFIG. 13.

FIG. 7is a pattern diagram depicting the regular process;FIG. 12is a flow chart depicting a file access process; andFIG. 13is a flow chart depicting a destage process.

When receiving a file access request indication from a user (FIG.7(1)), the client80transmits the file access request received to the LPAR1(FIG.7(2)).

A file sharing program1of the LPAR1determines whether the file access request is a write request or a read request (S21) when receiving a file access request from the client80. As a result, if the file access request is a write request (FIG. 12(S21: Yes)), the file sharing program1acquires the lock for the file to be accessed in accordance with the file access request, and reflects the details of the acquired lock in the takeover information management table110in the shared memory area212(FIG. 12(S22), FIG.7(3)). The file sharing program1sends a file write request (FIG. 12(S23), FIG.7(4)) to a file system1.

The file system1executes the write process in response to the write request for the file in the memory area1(occupied memory area1) (FIG. 12(S24), FIG.7(5)). Note that, as shown inFIG. 13, the file system52determines whether or not there is sufficient free space in the memory area1(FIG. 13(S41)), and if there is insufficient free space in the memory area1(FIG. 13(S41: No), it destages a file with a low rate of utilization, in other words, writes a file with a low rate of utilization from the memory area1to the LU311(FIG. 13(S42), FIG.7(6)).

After the write process has been executed by the file system1, the file sharing program1sends a response back to the client80originating the request (FIG. 12(S25)), removes the lock, deletes the details of the removed lock from the takeover information management table110in the shared memory area212(FIG. 12(S26)), and ends the file access process.

If, on the other hand, the file access request is a read request (FIG. 12(S21: No)), the file sharing program1acquires the lock for the file to be accessed in accordance with the file access request, and reflects the details of the acquired lock in the takeover information management table110in the shared memory area212(FIG. 12(S27), FIG.7(3)). The file sharing program51sends a file read request to the file system52(FIG. 12(S28), FIG.7(4)).

The file system1executes the read process in response to the read request for the file in the memory area1(occupied memory area1) (FIG. 12(S29), FIG.7(5)).

After the read process has been executed by the file system1, the file sharing program1sends the acquired file back to the client80originating the request (FIG. 12(S30)), removes the lock, deletes the details of the removed lock from the takeover information management table110in the shared memory area212(FIG. 12(S31)), and ends the file access process.

The following is a description of the fault monitoring process, in reference toFIG. 8,FIG. 9,FIG. 15,FIG. 16, andFIG. 17.

FIG. 8is a pattern diagram of part of the fault monitoring process;FIG. 9is a pattern diagram of the rest of the fault monitoring process;FIG. 15is a flow chart depicting a counter updating process;FIG. 16is a flow chart depicting a fault confirmation process and failover process; andFIG. 17is a flow chart depicting a counter monitoring process.

As shown inFIG. 8, the failover programs1and2update the counter values corresponding to each LPAR in the fault monitoring management table120at the specified intervals of time (FIG.8(1), FIG.15(S51)).

At the same time, the hypervisor60confirms the counter value corresponding to each LPAR in the fault monitoring management table120(FIG.8(2),FIG. 17(S81)), and determines whether each counter has been updated within the specified period (FIG. 17(S82)). As a result, if the counter has been updated (S82: Yes), the hypervisor60moves the process to S81, and if it has not been updated (S82: No), the hypervisor60configures the value of the fault flag120cin the fault monitoring management table120to ON (FIG.8(3),FIG. 17(S83)). This notifies that a fault occurs in the LPAR.

Next, the failover program1(2) monitors the value of the fault flag120cin the fault monitoring management table120in the shared memory area212, via the kernel/driver1(2) and hypervisor60(FIG.9(1),FIG. 16(S61)).

The failover program1(2) determines whether or not a fault occurs (S62). Specifically, the failover program1(2) determines that a fault occurs if the value of the fault flag120cin the fault monitoring management table120in the shared memory area212is ON. As a result, if no fault occurs (FIG. 16(S62: No)), the failover program1(2) moves the process on to S61, while if a fault occurs (S62: Yes), it executes the failover processes (S63to S67) described below.

Herein, the operation of the computer system is described by way of an example when a fault has occurred.

FIG. 14is a sequence diagram showing the fault monitoring process and failover process.

If no fault occurs in either the LPAR1or the LPAR2, then S51of the counter update process shown inFIG. 15, takes place, in which the failover program1updates a count value 1 (count value of the counter1120a) on the fault monitoring management table120at the specified intervals of time (FIG.14(1)), and a failover program2updates a count value 2 (count value of the counter 2120bcorresponding to the LPAR2) on the fault monitoring management table120at the specified intervals of time (FIG.14(2)). As a result, the hypervisor60does not configure the value of the fault flag120cin the fault monitoring management table120to ON (FIG.14(3)) in the counter monitoring process (FIG. 17).

If, however, a fault occurs in the LPAR1, the failover program1becomes unable to update the count value 1 in S51of the counter update process (FIG.14(4)). As a result, in the counter monitoring process subsequently implemented (FIG. 17), the fact that the count value 1 has not been updated for a given period is detected, and the value of the fault flag120con the fault monitoring management table120is configured to ON (FIG.14(5)).

Subsequently, when the failover program2of the LPAR2executes the fault confirmation process and failover process depicted inFIG. 16, the value of the fault flag120con the fault monitoring management table120is configured to ON. As a result the fact that a fault occurs is determined in S62, and the following failover processes (S63to S67) are executed (FIG.14(6)).

Next, there follows a description of the failover process that takes place if a fault occurs in LPAR, in reference toFIG. 10andFIG. 16. One LPAR in which the fault has occurred is defined as LPAR1, while the other LPAR is defined as LPAR2.

The failover program2which detects that a fault has occurred in the LPAR1, acquires resource group information (specifically, the information configured to the resource group100don the cluster configuration management table100) from the cluster configuration management table100in the shared memory area212, via the kernel/driver2and the hypervisor60(FIG.10(1),FIG. 16(S63)). Next, the failover program2checks the file system specified from the resource group information, and mounts the file system on the LPAR2(FIG.10(2),FIG. 16(S64)). In this way, the LPAR2becomes able to use the file system used by the LPAR1.

Next, the failover program53configures the IP address included in the resource group information as the IP address of the LPAR2(FIG.10(3),FIG. 16(S65)). In this way, the LPAR2becomes able to receive access requests received by the LPAR1from the client80.

Next, the failover program2acquires takeover information (specifically the information configured to the NFS configuration information110a, the CIFS configuration information110b, and the lock information110cin the takeover information management table110) from the takeover information management table110in the shared memory area212, via the kernel/driver2and the hypervisor60, and configures a file sharing program2on the basis of the acquired information (FIG.10(4),FIG. 16(S66)), and reopens operation by the file sharing program2, making it possible to receive access requests from the client80(FIG.10(5)).

In this way, the file sharing program2is configured on the basis of information configured to the NFS configuration information110a, the CIFS configuration information110b, and the lock information110c.As a result, the file sharing program2is able to provide a file sharing service in the same usage state as that of the file sharing program1in the LPAR1. For example, it is possible to provide, to the client80which has published a file system in the LPAR1, a file sharing service with the same right to access. Furthermore, the lock status resulting from the file system in the LPAR1being used can be maintained. As a result, if a certain file is locked as a result of a file access request from a certain client80, even if a fault has occurred in the LPAR1, the state of the lock can be taken over by the LPAR2, preventing the locked file from being occupied by another client80, and facilitating the continuation of file access by the client80.

Next, the failover program2executes a reset process (FIGS. 16(S71to S73) to reset the LPAR1where the fault has occurred (FIG. 16(S64)). It is noted that the reset process is executed in such a way that the data in the memory area1of the LPAR1where the fault has occurred, is not cleared (deleted).

In the reset process, the failover program2loads the OS into an unused area of the memory area1in the LPAR1where the fault has occurred, and starts up the OS (FIG. 16(S71)).

Next, the failover program2reads the data in the area actually utilized within the memory area1in the LPAR1where the fault has occurred, via the kernel/driver2and hypervisor60(FIG. 16(S72)), and outputs the read data as a file (FIG. 16(S73)). In this way, the information in the memory area I used by the LPAR1where the fault has occurred, can be turned appropriately into a file.

Next, there follows a detailed description of part of the processes in the computer system.

FIG. 18is a sequence diagram describing access to the shared memory area. The sequence depicted inFIG. 18relates to the processes of S12through S14depicted inFIGS. 11, and S63and S66inFIG. 16.

First, there follows a description of the processes relating to a process for retaining a shared memory area (S12).

The failover program1of the LPAR1sends a shared memory area retention request, with the size specified, to the hypervisor60(S91). The size specified here takes into consideration, for example, the initial size of the cluster configuration management table100, the takeover information management table110, and the fault monitoring management table120, as well as the increase in size anticipated in the takeover information management table110, which is expected to increase after operation begins. When receiving a shared memory area retention request, the hypervisor60retains an area for a shared memory area212having the size in line with the request (S92). Next, the hypervisor60transmits a handle to the LPAR1in order to allow the shared memory area212to be uniquely identified (S93). Here, the handle may contain, for example, the ID of the LPAR1that made the shared memory area retention request, and the initial address of the shared memory area212within a memory area21.

Next, there follows a description of the processes related to the process of storing data (S13) to the retained shared memory area212.

The LPAR1transmits a write request, including the received handle, the offset which is the size of the data to be written, and the data, to the hypervisor60(S94) when storing data in the shared memory area212. The hypervisor60stores data in the shared memory area212in line with the write request (S95), and transmits the results of the write request process to the LPAR1(S96).

The LPAR1transmits the handle needed to access the shared memory area212to the LPAR2(S97). The failover program2of the LPAR2stores the handle needed to access the shared memory area in the memory area2of the LPAR2(S98). Using the handle, the LPAR2is able to appropriately access the retained shared memory area212.

Next, there follows a description of the processes related to the process in which the LPAR2is used to read the data stored in the shared memory area212(S63, S66).

If there is a need to read the data from the shared memory area212(S63, S66), the failover program2of the LPAR2transmits a read request including the handle stored in the memory area2of the LPAR2and the offset which is the size of the data to be read, to the hypervisor60(S99). The hypervisor60reads the data from the shared memory area212in line with the read request (S100) and transmits the read data to the LPAR2.

In this way, the shared memory area212can be retained at a time point when required, and since the LPAR2is passed a handle that allows it to identify the shared memory area212, there is no need to prepare the shared memory area212in advance.

FIG. 19is a sequence diagram depicting a memory dump process. The sequence depicted inFIG. 19mainly corresponds to the processes for each configuration relating to S72and S73inFIG. 16.

In S72, the failover program2of the LPAR2transmits, to the hypervisor60, an acquisition request for information on the memory area1(occupied memory area1) of the LPAR1(S111). The hypervisor60accesses the occupied memory area1in line with the acquisition request for information on the occupied memory area1information (S112), and acquires the LPAR1occupied memory area information (S113). Here, the hypervisor60ascertains the state of the memory area1of the LPAR1, and since a fault occurs in the LPAR1and the occupied memory area1is not in use, can easily acquire the LPAR1occupied memory area information without executing exclusive control. Next, the hypervisor60returns the acquired occupied memory area information to the LPAR2(S114). The failover program2of the LPAR2which has received the return of the occupied memory area information from the hypervisor60, writes the occupied memory area information to the PDEV (S73). As a result, even if a fault occurs in the LPAR1, it is possible to appropriately collect the information on the LPAR1occupied memory area1, and appropriately analyze, etc., the fault.

Although one embodiment is described above, it is needless to say that the present invention is not limited to this embodiment, and that numerous modifications may be made to it without departing from the gist thereof. It is possible, for example, for the hypervisor60to directly notify the failover program53of another LPAR that a fault has occurred in the LPAR.

REFERENCE SIGNS LIST