WO2015052836A1 - ストレージ装置及びフェールオーバ方法 - Google Patents

ストレージ装置及びフェールオーバ方法 Download PDF

Info

Publication number
WO2015052836A1
WO2015052836A1 PCT/JP2013/077783 JP2013077783W WO2015052836A1 WO 2015052836 A1 WO2015052836 A1 WO 2015052836A1 JP 2013077783 W JP2013077783 W JP 2013077783W WO 2015052836 A1 WO2015052836 A1 WO 2015052836A1
Authority
WO
WIPO (PCT)
Prior art keywords
logical partition
memory area
takeover
shared memory
information
Prior art date
Application number
PCT/JP2013/077783
Other languages
English (en)
French (fr)
Inventor
真幹 五味
信之 雜賀
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US14/371,147 priority Critical patent/US9262289B2/en
Priority to PCT/JP2013/077783 priority patent/WO2015052836A1/ja
Publication of WO2015052836A1 publication Critical patent/WO2015052836A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2043—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share a common memory address space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking

Definitions

  • the present invention relates to failover between a plurality of logical partitions (LPARs).
  • LPARs logical partitions
  • the elements constituting the network are generally called nodes, but a cluster in which a plurality of nodes (for example, server machines) are connected is known.
  • a cluster refers to a system that behaves as if it is a single node (device) as a whole with respect to external devices.
  • failover is performed in which another node takes over processing and data.
  • the storage device has a virtualization mechanism that manages the first and second LPARs (logical partitions) to which the first and second logical resources obtained by logically dividing the physical resources of the storage device are respectively assigned.
  • the virtualization mechanism is a memory-based area and provides a shared memory area accessible by the first and second LPARs.
  • the first LPAR stores, in the shared memory area, takeover necessary information necessary for taking over the data input / output processing handled by the first LPAR to the second LPAR.
  • the second LPAR When the second LPAR detects the occurrence of a failure in the first LPAR, the second LPAR acquires takeover necessary information from the shared memory area, and takes over and executes the data input / output processing that the first LPAR was in charge of based on the takeover necessary information .
  • information may be described using an expression such as “aaa table”, but the information may be expressed using a data structure other than a table.
  • aaa table or the like can be called “aaa information”.
  • processing may be described using a program as a subject, but the program is executed by a processor (for example, a CPU (Central Processing Unit)), so that a predetermined process can be appropriately performed as a storage resource. Since the processing is performed using (for example, a memory) and / or a communication interface, the subject of processing may be a processor.
  • the processor may include a hardware circuit that performs part or all of the processing.
  • the computer program may be installed in the computer from a program source.
  • the program source may be, for example, a program distribution server or a storage medium that can be read by a computer.
  • LPAR is an abbreviation for Logical Partition, and is a virtual machine to which logical resources obtained by logically dividing physical resources are assigned. The LPAR is recognized as one device by an external device (for example, a client).
  • a “hypervisor” is a type of virtualization mechanism that generates and operates an LPAR.
  • Node means an element constituting a network. In this embodiment, the node is an LPAR that is a component of the cluster.
  • a “cluster” is a system composed of a plurality of nodes that behaves as if it is a single node (device) as a whole with respect to an external device (for example, a client).
  • “Failover” means that the second device takes over processing or data when a failure occurs in the first device, or its function.
  • Each of the first device and the second device may be a physical device or a logical device. In the present embodiment, both the first and second devices are LPARs.
  • the computer system is an example of a storage device and has an integrated platform device 10 connected to a client 80.
  • a plurality of LPARs 50 generated by the hypervisor 60 operate.
  • the hypervisor 60 manages a plurality of logical resources obtained by logically dividing a physical resource including a memory and an allocation destination LPAR of each of the plurality of logical resources.
  • As the LPAR 50 there are LPAR 1 and 2.
  • LPAR 1 and 2 By logically dividing the memory, the memory area 1, the memory area 2, and the shared memory area 212 are obtained as logical resources.
  • Memory area 1 is assigned to LPAR1
  • memory area 2 is assigned to LPAR2.
  • a shared memory area that can be accessed by both LPAR 1 and 2 is allocated to LPAR 1 and 2.
  • the LPAR1 stores the takeover required information for taking over the operation of the LPAR1 to the LPAR2 in the shared memory area 212 (FIG. 20 (1)).
  • the takeover necessary information includes, for example, information on resource groups in LPAR1, setting information in the file system, information on locking of files in the file system (lock information), and the like.
  • the LPAR1 receives a file access request from the client 80 (FIG. 20 (2))
  • the LPAR1 reflects the lock information for the access request target file in the takeover information of the shared memory area 212 (FIG. 20 (3)).
  • the LPAR 2 When the LPAR 2 recognizes that a failure has occurred in the LPAR 1, the LPAR 2 acquires the takeover required information of the shared memory area 212 and performs various settings based on the takeover required information. Thereby, LPAR2 takes over and executes the processing by LPAR1. As described above, according to the present embodiment, the takeover necessary information can be acquired from the shared memory area 212. Therefore, when a failure occurs in the LPAR1, it is possible to quickly fail over.
  • Fig. 1 is a block diagram of a computer system.
  • the computer system includes a plurality (or one) of clients 80 and an integrated platform device 10 to which a plurality of clients 80 are connected.
  • the client 80 and the integrated platform device 10 are connected via a communication network such as a TCP / IP network, for example.
  • the client 80 is an example of a host device, and is a computer that executes data access (read, write) in units of files to the integrated platform device 10. Specifically, the client 80 issues a file access request (file read request or write request) to the integrated platform device 10.
  • the client 80 includes a memory 81, a NIC (Network Interface card) 83, a physical storage device (hereinafter referred to as PDEV) 84, and a CPU 82 connected thereto.
  • the memory 81 stores programs and data used by the CPU 82.
  • the CPU 82 executes various processes by executing programs stored in the memory 81.
  • the NIC 83 is an example of a communication interface device for connecting to another device (for example, the integrated platform device 10).
  • the PDEV 84 is a non-volatile storage device such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive).
  • the PDEV 84 may store a program for controlling the client 80 such as an OS (Operating System) executed by the CPU 82.
  • OS Operating System
  • the integrated platform device 10 includes a server unit 20 and a storage unit 11.
  • the server unit 20 and the storage unit 11 are connected via an internal data bus (for example, a PCIe bus) 40.
  • an internal data bus for example, a PCIe bus
  • the server unit 20 may be a circuit board (for example, a blade server).
  • the server unit 20 includes a memory 21, a NIC 23, an internal I / F 24, and a CPU 22 connected thereto.
  • the memory 21 is a DRAM (Dynamic Random Access Memory), for example, and stores various programs and data executed by the CPU 22.
  • the CPU 22 executes various processes by executing various programs stored in the memory 21.
  • the NIC 23 is an example of a communication interface device for connecting to another device (for example, the client 80).
  • the server unit 20 executes one or a plurality of OSs to provide a file server function and execute an application.
  • the internal I / F 24 is an example of a communication interface device for communicating via the internal data bus 40.
  • the server unit 20 receives the file access request from the client 80, and transmits a block I / O request (I / O request for the data block constituting the file to be accessed) based on the access request to the storage unit 11.
  • the storage unit 11 includes a plurality of PDEVs 31 and a RAID (Redundant Array of Independent (or Inexpensive) Disks) control unit 30 connected to the plurality of PDEVs 31.
  • a RAID group may be configured by two or more PDEVs 31.
  • An LU (Logical Unit) is configured based on the RAID group.
  • the RAID control unit 30 is a module (for example, a circuit board) that controls access to the PDEV 31, and may include a communication interface device for communicating via the internal data bus 40, a memory, and a CPU connected thereto. .
  • the RAID control unit 30 receives a block-level I / O request from the server unit 20, and executes I / O processing (read processing / write processing) for the PDEV 31 according to the I / O request.
  • FIG. 2 is a block diagram including the computer system software.
  • the integrated platform device 10 is connected to the management computer 90 in addition to the client 80.
  • the management computer 90 is a computer used by a computer system administrator to manage the computer system. For example, the management computer 90 receives various instructions from the administrator and transmits them to the integrated platform device 10.
  • the hypervisor 60 on the memory 21 is executed by the CPU 22.
  • the hypervisor 60 manages logical resources obtained by logically dividing physical resources (memory 21, CPU 22, NIC 23, etc.) of the integrated platform device 10.
  • the hypervisor 60 generates an LPAR 50 to which logical resources are allocated.
  • An OS may be executed in each LPAR 50.
  • the hypervisor 60 logically divides the memory 21 to prepare a memory area 1 for LPAR1, a memory area 2 for LPAR2, and a shared memory area 212 for LPAR1 and LPAR2.
  • a cluster configuration management table 100 see FIG. 3
  • a takeover information management table 110 see FIG. 4
  • a failure monitoring management table 130 see FIG. 5
  • CPU1 and CPU2 are obtained as logical resources by logically dividing CPU22.
  • CPU 1 is a CPU of LPAR 1 (logical resource allocated to LPAR 1)
  • CPU 2 is a CPU of LPAR 2.
  • the LPAR 50 executes a file sharing program 51, a file system 52, a failover program 53, and a kernel / driver 54.
  • the file sharing program 51 provides a file sharing service that can share files among a plurality of clients using a communication protocol such as CIFS (Common Internet File System) and NFS (Network File System).
  • CIFS Common Internet File System
  • NFS Network File System
  • the file system 52 includes a logical structure constructed in order to realize a management unit called a file on the LU 311.
  • the file system 52 includes a file system program that manages the logical structure.
  • the file system 52 includes a super block, an inode management table, and a data block as a logical structure. Since the super block, the inode management table, and the data block are publicly known, only a brief description will be given here.
  • the super block collectively holds file system information. For example, the super block holds management information of the entire file system such as the size of the file system and the free capacity of the file system.
  • the inode management table manages meta information of individual files / directories. The inode management table also manages addresses to data blocks for files. Note that the structure of the file system 52 is stored in the LU 311, and a part or all of the structure is called to the LPAR memory area.
  • the failover program 53 monitors the occurrence of a failure in another LPAR 50 in the same cluster. If a failure is detected, the failover program 53 takes over the resources (IP address, file system, etc.) operating in the LPAR 50 that is the failure source, Failover is executed to restart the file sharing service that was being executed by the original LPAR 50.
  • resources IP address, file system, etc.
  • the kernel / driver 54 performs general control and hardware-specific control such as controlling the schedule of a plurality of programs (processes) operating on the integrated platform apparatus 10 and handling interrupts from hardware. It is a program to be performed.
  • the RAID control unit 30 executes input / output processing for the LU 311 based on the RAID group.
  • a program executed by LPAR n or a logical resource allocated to LPAR n may be described using a number n instead of a reference symbol.
  • FIG. 3 is a configuration diagram of an example of the cluster configuration management table.
  • the cluster configuration management table 100 has fields of a counterpart node name 100a, a monitoring interval 100b, a resource group number 100c, and a resource group 100d.
  • the node name of the counterpart node (LPAR) having a cluster configuration is stored.
  • the monitoring interval 100b stores a time interval for performing failure monitoring.
  • the resource group number 100c stores the number of resource groups obtained by grouping resources necessary for providing the file sharing service in the LPAR.
  • the number of resource groups 100d is equal to or greater than the number of resource groups set to the resource group number 100c.
  • the resource group 100d includes information on the resource group (resource group information), for example, an IP address for accessing the resource group from the client 80, the number of file systems belonging to the resource group, and each file belonging to the resource group Stores the file system name of the system.
  • FIG. 4 is a configuration diagram of an example of the takeover information management table.
  • the takeover information management table 110 includes fields for NFS setting information 110a, CIFS setting information 110b, and lock information 110c.
  • the NFS setting information 110a and the CIFS setting information 110b store a public IP address, a public dir name, and an access right, respectively.
  • the public IP address is an IP address of a computer (client or the like) that discloses the file system.
  • the public dir name is the name of a public directory.
  • the public directory may be a directory in the file system, a root directory of the file system, or a root directory of the global namespace.
  • the access right indicates what kind of access is permitted to the disclosure destination. Access rights include read only permission, read and write permission, and the like.
  • the file name and the IP address are stored in the lock information 110c.
  • the file name is the name of the file to be locked.
  • the IP address is the IP address of the computer (lock owner) that locks the file with the file name.
  • the entire information stored in the cluster configuration management table 100 may be referred to as “cluster configuration information”, and the entire information stored in the takeover information management table 110 may be referred to as “takeover information”.
  • Information set in the cluster configuration management table 100 and the takeover information management table 110 is an example of takeover required information.
  • FIG. 5 is a configuration diagram of an example of the failure monitoring management table.
  • the failure monitoring management table 120 has fields of counter 1 120a, counter 2 120b, and failure flag 120c.
  • the counter 1 120a stores a count value counted up by LPAR1.
  • the counter 2 120b stores a count value counted up by LPAR2.
  • the count value may be updated by another method such as countdown instead of counting up.
  • the count value is an example of confirmation information.
  • the failure flag 120c stores a flag (failure flag) indicating whether or not a failure has occurred in the LPAR.
  • the failure flag is set to ON when the hypervisor 60 detects a LPAR failure.
  • FIG. 6 is a schematic diagram of the initial process
  • FIG. 11 is a flowchart of the initial process.
  • the management computer 90 When the management computer 90 receives the cluster configuration information and takeover information for LPAR1 from the administrator and receives an instruction for the cluster configuration request (FIG. 6 (1)), the integrated platform device receives the received cluster configuration information and takeover information. 10 LPAR1s are transmitted (FIG. 6 (2)).
  • the failover program 1 of LPAR1 receives the cluster configuration information and the takeover information from the management computer 90 (FIG. 11 (S11)), and requests the kernel / driver 54 to secure a shared memory area (FIG. 11 (S12)). FIG. 6 (3)).
  • the kernel / driver 54 requests the hypervisor 60 to secure a shared memory area (FIG. 6 (4)).
  • the hypervisor 60 that has received the request for securing the shared memory area secures the shared memory area 212 from the memory 21 (FIG. 6 (5)).
  • the failover program 1 registers the cluster configuration information as the cluster configuration management table 100 in the shared memory area 212 via the kernel / driver 1 (FIG. 11 (S13), FIG. 6)), the takeover information is registered in the shared memory area 212 as the takeover information management table 110 (FIG. 11 (S14), FIG. 6 (6)). Note that at least one of a part of the cluster configuration information and a part of the takeover information may be stored in at least one LU 311 instead of or in addition to the shared memory area 212.
  • the failover program 1 starts a failure monitoring process (see FIGS. 8, 15, 16, and 17) (S15).
  • FIG. 7 is a schematic diagram of normal processing
  • FIG. 12 is a flowchart of file access processing
  • FIG. 13 is a flowchart of destage processing.
  • the client 80 When the client 80 receives a file access request instruction from the user (FIG. 7 (1)), the client 80 transmits the received file access request to the LPAR 1 (FIG. 7 (2)).
  • the file sharing program 1 of LPAR1 When the file sharing program 1 of LPAR1 receives the file access request from the client 80, it determines whether the file access request is a write request or a read request (S21). As a result, when the file access request is a write request (FIG. 12 (S21: Yes)), the file sharing program 1 acquires the lock of the access target file according to the file access request, and takes over the shared memory area 212 information. The contents of the acquired lock are reflected in the management table 110 (FIG. 12 (S22), FIG. 7 (3)). The file sharing program 1 makes a file write request to the file system 1 (FIG. 12 (S23), FIG. 7 (4)).
  • the file system 1 executes a write process corresponding to the write request for the file in the memory area 1 (occupied memory area 1) (FIG. 12 (S24), FIG. 7 (5)). As shown in FIG. 13, the file system 52 determines whether there is sufficient space in the memory area 1 (FIG. 13 (S41)), and when there is not enough space in the memory area 1 (FIG. 13). (S41: No)), a file with a low usage rate is destaged, that is, a file with a low usage rate is written from the memory area 1 to the LU 311 (FIG. 13 (S42), FIG. 7 (6)).
  • the file sharing program 1 After execution of the write process by the file system 1, the file sharing program 1 returns a response to the requesting client 80 (FIG. 12 (S25)), releases the lock, and from the takeover information management table 110 in the shared memory area 212, The contents of the released lock are deleted (FIG. 12 (S26)), and the file access process is terminated.
  • the file sharing program 1 acquires the lock of the file to be accessed according to the file access request and takes over the shared memory area 212.
  • the contents of the acquired lock are reflected in the management table 110 (FIG. 12 (S27), FIG. 7 (3)).
  • the file sharing program 51 makes a file read request to the file system 52 (FIG. 12 (S28), FIG. 7 (4)).
  • the file system 1 executes a read process corresponding to the read request on the file in the memory area 1 (occupied memory area 1) (FIG. 12 (S29), FIG. 7 (5)).
  • the file sharing program 1 After executing the read process by the file system 1, the file sharing program 1 returns the acquired file to the requesting client 80 (FIG. 12 (S30)), releases the lock, and the takeover information management table 110 in the shared memory area 212. The contents of the unlocked lock are deleted (FIG. 12 (S31)), and the file access process is terminated.
  • FIG. 8 is a schematic diagram of a part of the fault monitoring process
  • FIG. 9 is a schematic diagram of the remaining part of the fault monitoring process
  • FIG. 15 is a flowchart of the counter update process
  • FIG. 16 is a fault confirmation process.
  • FIG. 17 is a flowchart of the counter monitoring process.
  • the failover programs 1 and 2 update the value of the counter corresponding to each LPAR in the failure monitoring management table 120 every predetermined time (FIG. 8 (1), FIG. 15 (S51)). .
  • the hypervisor 60 checks the value of the counter corresponding to each LPAR in the failure monitoring management table 120 (FIG. 8 (2), FIG. 17 (S81)), and whether each counter has been updated within a certain period. Is determined (FIG. 17 (S82)). As a result, if it has been updated (S82: Yes), the hypervisor 60 advances the processing to S81, and if it has not been updated (S82: No), the value of the failure flag 120c of the failure monitoring management table 120 Is set to ON (FIG. 8 (3), FIG. 17 (S83)). This is for notifying that a failure has occurred in the LPAR.
  • the failover program 1 (2) monitors the value of the failure flag 120c of the failure monitoring management table 120 in the shared memory area 212 via the kernel / driver 1 (2) and the hypervisor 60 (FIG. 9 (1)).
  • Failover program 1 (2) determines whether or not a failure has occurred (S62). Specifically, the failover program 1 (2) determines that a failure has occurred when the value of the failure flag 120c in the failure monitoring management table 120 of the shared memory area 212 is ON. As a result, when no failure has occurred (FIG. 16 (S62: No)), the failover program 1 (2) advances the process to S61, and when a failure has occurred (S62: Yes). Then, a failover process (S63 to S67) described later is executed.
  • FIG. 14 is a sequence diagram of failure monitoring processing and failover processing.
  • the failover program 1 sets the count value 1 (count value of the counter 1 120a) in the failure monitoring management table 120 to a predetermined value by S51 of the counter update process shown in FIG. (FIG. 14 (1)), and the failover program 2 updates the count value 2 of the failure monitoring management table 120 (count value of the counter 2 120b corresponding to LPAR2) every predetermined time (FIG. 14). 14 (2)).
  • the value of the failure flag 120c in the failure monitoring management table 120 is not set to ON (FIG. 14 (3)).
  • the failover program 2 of the LPAR2 executes the failure confirmation processing and failover processing shown in FIG. 16, the failure flag 120c of the failure monitoring management table 120 is set to ON, so that a failure occurs in S62.
  • the subsequent failover processing (S63 to S67) is executed (FIG. 14 (6)).
  • LPAR1 One LPAR in which a failure has occurred is designated LPAR1, and the other LPAR is designated LPAR2.
  • the failover program 2 that has detected that a failure has occurred in the LPAR 1 receives the resource group information (specifically, the cluster configuration management table) from the cluster configuration management table 100 in the shared memory area 212 via the kernel / driver 2 and the hypervisor 60. 100 resource groups (information set in 100d) (FIG. 10 (1), FIG. 16 (S63)). Next, the failover program 2 checks the file system specified from the resource group information, and mounts the file system on the LPAR 2 (FIG. 10 (2), FIG. 16 (S64)). As a result, the LPAR2 can use the file system used by the LPAR1.
  • the resource group information specifically, the cluster configuration management table
  • 100 resource groups information set in 100d
  • the failover program 2 checks the file system specified from the resource group information, and mounts the file system on the LPAR 2 (FIG. 10 (2), FIG. 16 (S64)). As a result, the LPAR2 can use the file system used by the LPAR1.
  • the failover program 53 sets the IP address included in the resource group information to the IP address of LPAR2 (FIG. 10 (3), FIG. 16 (S65)).
  • the LPAR 2 can receive the access request that the LPAR 1 received from the client 80.
  • the failover program 2 receives the takeover information (specifically, the NFS setting information 110a, CIFS of the takeover information management table 110) from the takeover information management table 110 of the shared memory area 212 via the kernel / driver 2 and the hypervisor 60.
  • Information set in the setting information 110b and the lock information 110c), and the file sharing program 2 is set based on the acquired information (FIG. 10 (4), FIG. 16 (S66)).
  • the operation is resumed so that an access request from the client 80 can be accepted (FIG. 10 (5)).
  • the file sharing program 2 is changed to the usage status of the file sharing program 1 in the LPAR1.
  • a file sharing service can be provided in the same state. For example, it is possible to provide a file sharing service with the same access right to the client 80 that has disclosed the file system in LPAR1. Further, the lock state when the file system is used in the LPAR 1 can be maintained. Therefore, even when a failure occurs in LPAR1 in a state where a file is locked by a file access request from a client 80, the lock state can be taken over in LPAR2. Therefore, the locked file can be prevented from being occupied by another client 80, and the file access to the client 80 can be continued.
  • the failover program 2 performs a reset process (FIG. 16 (S71 to S73)) for resetting the failed LPAR1 (FIG. 16 (S64)).
  • a reset process for resetting the failed LPAR1 (FIG. 16 (S64)).
  • the data in the memory area 1 of the LPAR 1 where the failure has occurred is not cleared (erased).
  • the failover program 2 loads the OS into an unused area in the memory area 1 of the failed LPAR 1 and starts the OS (FIG. 16 (S71)).
  • the failover program 2 reads the data of the area actually used in the memory area 1 of the failed LPAR1 via the kernel / driver 2 and the hypervisor 60 (FIG. 16 (S72)).
  • the data is output as a file (FIG. 16 (S73)).
  • the information in the memory area 1 used by the failed LPAR 1 can be appropriately converted into a file.
  • FIG. 18 is a sequence diagram for explaining access to the shared memory area.
  • the sequence shown in FIG. 18 relates to the processes of S12 to S14 shown in FIG. 11 and the processes of S63 and S66 shown in FIG.
  • the failover program 1 of LPAR1 transmits a shared memory area securing request with the size specified to the hypervisor 60 (S91).
  • the size specified here for example, the initial sizes of the cluster configuration management table 100, the takeover information management table 110, and the failure monitoring management table 120, and the increment of the takeover information management table 110 that is expected to increase after the operation is started, are used. The size is taken into account.
  • the hypervisor 60 secures an area of the shared memory area 212 having a size according to the request (S92).
  • the hypervisor 60 transmits a handle for uniquely identifying the shared memory area 212 to LPAR1 (S93).
  • the handle includes, for example, the ID of LPAR1 that has made a shared memory area securing request, and the start address of the shared memory area 212 in the memory area 21.
  • the LPAR 1 When storing data in the shared memory area 212, the LPAR 1 transmits a received request, an offset that is the size of data to be written, and a write request including the data to the hypervisor 60 (S94).
  • the hypervisor 60 stores data in the shared memory area 212 in accordance with the write request (S95), and transmits the processing result of the write request to LPAR1 (S96).
  • the LPAR1 transmits a handle for accessing the shared memory area 212 to the LPAR2 (S97).
  • the failover program 2 of the LPAR2 stores a handle for accessing the shared memory area in the memory area 2 of the LPAR2 (S98). With this handle, the LPAR 2 can appropriately access the reserved shared memory area 212.
  • the failover program 2 of the LPAR2 When it is necessary to read data from the shared memory area 212 (S63, S66), the failover program 2 of the LPAR2 includes a handle stored in the memory area 2 of the LPAR2 and an offset indicating the size of the read data.
  • a read request is transmitted to the hypervisor 60 (S99).
  • the hypervisor 60 reads data from the shared memory area 212 according to the read request (S100), and transmits the read data to the LPAR 2 (S101).
  • the shared memory area 212 is secured at a necessary time and a handle for specifying the shared memory area 212 is passed to the LPAR 2, it is not necessary to prepare the shared memory area 212 in advance. .
  • FIG. 19 is a sequence diagram of the memory dump process.
  • the sequence shown in FIG. 19 mainly corresponds to the processing of each configuration related to S72 and S73 of FIG.
  • the failover program 2 of the LPAR2 transmits an information acquisition request for the memory area 1 (occupied memory area 1) of the LPAR1 to the hypervisor 60 (S111).
  • the hypervisor 60 accesses the occupied memory area 1 in accordance with the acquisition request for information on the occupied memory area 1 (S112), and obtains the occupied memory area information of LPAR1 (S113).
  • the hypervisor 60 knows the state of the memory area 1 of the LPAR1, and a failure occurs in the LPAR1, and the occupied memory area 1 is not used. Therefore, the hypervisor 60 can easily perform the LPAR1 without performing exclusive control. Occupied memory area information can be acquired.
  • the hypervisor 60 returns the acquired occupied memory area information to the LPAR 2 (S114).
  • the failover program 2 of LPAR2 that has received the return of the occupied memory area information from the hypervisor 60 writes the occupied memory area information to the PDEV (S73).
  • the hypervisor 60 may notify the failover program 53 of another LPAR directly that a failure has occurred in the LPAR.
  • Integrated platform device 20 Server unit 30: RAID control unit 80: Client 90: Management computer

Abstract

　ストレージ装置は、ストレージ装置の物理リソースを論理的に分割することにより得られた第１及び第２論理リソースがそれぞれ割り当てられた第１及び第２ＬＰＡＲ（論理区画）を管理する仮想化機構を有する。仮想化機構は、メモリに基づく領域であり第１及び第２ＬＰＡＲがアクセス可能な共有メモリ領域を提供する。第１ＬＰＡＲは、共有メモリ領域に対して、第１ＬＰＡＲが担当しているデータ入出力処理を第２ＬＰＡＲに引継ぐために必要な引継ぎ必要情報を格納する。第２ＬＰＡＲは、第１ＬＰＡＲにおける障害の発生を検出した場合に、共有メモリ領域から引継ぎ必要情報を取得し、引継ぎ必要情報に基づいて、第１ＬＰＡＲが担当していたデータ入出力処理を引継いで実行する。

Description

ストレージ装置及びフェールオーバ方法
　本発明は、複数の論理区画（ＬＰＡＲ：Logical　Partition）間のフェールオーバに関する。
　ネットワークを構成する要素は一般にノードと呼ばれるが、複数のノード（例えば、サーバマシン）を連結したクラスタが知られている。ここで、クラスタとは、外部の装置に対して全体で１台のノード（装置）であるかのように振る舞うシステムをいう。クラスタでは、一般に、いずれかのノードに障害が発生した場合に、他のノードが処理やデータを引き継ぐフェールオーバが実行される。
　フェイルオーバに関して、例えば、フェールオーバ発生時であっても、ディスクＩ／Ｏ性能劣化を抑えながら、トランザクションの整合を図る技術が知られている（例えば、特許文献１参照）。また、物理計算機上のＬＰＡＲに障害が発生した場合に、他の物理計算機に交替先のＬＰＡＲを設定して、ＬＰＡＲ単位の交替を可能にする技術も知られている（例えば、特許文献２参照）。
特開２００８－２４２７４２号公報 特開２０１２－１９５００５号公報
　複数のＬＰＡＲを実行可能なストレージ装置では、いずれかのＬＰＡＲに障害が発生した場合に迅速に他のＬＰＡＲにフェールオーバすることが望ましい。
　ストレージ装置は、ストレージ装置の物理リソースを論理的に分割することにより得られた第１及び第２論理リソースがそれぞれ割り当てられた第１及び第２ＬＰＡＲ（論理区画）を管理する仮想化機構を有する。仮想化機構は、メモリに基づく領域であり第１及び第２ＬＰＡＲがアクセス可能な共有メモリ領域を提供する。第１ＬＰＡＲは、共有メモリ領域に対して、第１ＬＰＡＲが担当しているデータ入出力処理を第２ＬＰＡＲに引継ぐために必要な引継ぎ必要情報を格納する。第２ＬＰＡＲは、第１ＬＰＡＲにおける障害の発生を検出した場合に、共有メモリ領域から引継ぎ必要情報を取得し、引継ぎ必要情報に基づいて、第１ＬＰＡＲが担当していたデータ入出力処理を引継いで実行する。
　迅速にＬＰＡＲ間のフェールオーバを実行することができる。
計算機システムの構成図である。 計算機システムのソフトウェア含む構成図である。 クラスタ構成管理テーブルの一例の構成図である。 引継ぎ情報管理テーブルの一例の構成図である。 障害監視管理テーブルの一例の構成図である。 初期処理の模式図である。 通常処理の模式図である。 障害監視処理の一部分の模式図である。 障害監視処理の残り部分の模式図である。 フェールオーバ処理の模式図である。 初期処理のフローチャートである。 ファイルアクセス処理のフローチャートである。 デステージ処理のフローチャートである。 障害監視処理及びフェールオーバ処理のシーケンス図である。 カウンタ更新処理のフローチャートである。 障害監視処理及びフェールオーバ処理のフローチャートである。 カウンタ監視処理のフローチャートである。 共有メモリへのアクセスを説明するシーケンス図である。 メモリダンプ処理のシーケンス図である。 計算機システムの概要を示す。
　以下、図面を参照して一実施例を説明する。
　なお、以下の説明では「ａａａテーブル」等の表現にて情報を説明する場合があるが、情報は、テーブル等のデータ構造以外で表現されていてもよい。データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことができる。
　また、以下の説明では、プログラムを主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central　Processing　Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェースを用いながら行うため、処理の主語が、プロセッサとされても良い。また、プロセッサが、処理の一部又は全部を行うハードウェア回路を含んでも良い。コンピュータプログラムは、プログラムソースから計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機が読み取り可能な記憶メディアであっても良い。
　また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号を使用し、同種の要素を区別して説明する場合には、参照符号に代えて要素に割り振られた識別番号を使用することがある。
　また、以下の説明における用語の意味は、下記の通りである。
（＊）「ＬＰＡＲ」は、論理区画（Logical　Partition）の略であり、物理リソースを論理的に分割することにより得られた論理リソースが割り当てられた仮想マシンである。ＬＰＡＲは、外部の装置（例えばクライアント）に１つの装置として認識される。
（＊）「ハイパバイザ」は、ＬＰＡＲを生成して稼働さる仮想化機構の一種である。
（＊）「ノード」は、ネットワークを構成する要素を意味する。本実施例では、ノードは、クラスタの構成要素であるＬＰＡＲである。
（＊）「クラスタ」は、複数のノードで構成され外部の装置（例えばクライアント）に対して全体で１台のノード（装置）であるかのように振る舞うシステムである。
（＊）「フェールオーバ」は、第１装置に障害が発生した場合に第２装置が処理やデータを引き継ぐこと、またはその機能を意味する。第１装置及び第２装置は、それぞれ、物理的な装置であっても、論理的な装置であっても良い。本実施例では、第１及び第２装置のいずれもＬＰＡＲである。
　まず、図２０を参照して、実施例に係る計算機システムの概要を説明する。
　計算機システムが、ストレージ装置の一例でありクライアント８０に接続された統合プラットフォーム装置１０を有する。統合プラットフォーム装置１０において、ハイパバイザ６０によって生成された複数のＬＰＡＲ５０が動作する。ハイパバイザ６０は、メモリを含む物理リソースが論理的に分割されることにより得られた複数の論理リソースと、複数の論理リソースの各々の割当先ＬＰＡＲを管理する。ＬＰＡＲ５０として、ＬＰＡＲ１及び２がある。メモリを論理的に分割することにより、論理リソースとして、メモリ領域１、メモリ領域２及び共有メモリ領域２１２が得られる。ＬＰＡＲ１に、メモリ領域１が割り当てられ、ＬＰＡＲ２に、メモリ領域２が割り当てられる。また、ＬＰＡＲ１及び２に、ＬＰＡＲ１及び２のいずれもアクセス可能な共有メモリ領域が割り当てられる。
　ＬＰＡＲ１が、ＬＰＡＲ１の動作をＬＰＡＲ２に引継ぐ引継ぎ必要情報を、共有メモリ領域２１２に格納する（図２０（１））。ここで、引継ぎ必要情報としては、例えば、ＬＰＡＲ１におけるリソースグループに関する情報、ファイルシステムにおける設定情報、ファイルシステムにおけるファイルのロックに関する情報（ロック情報）等がある。ＬＰＡＲ１は、クライアント８０からファイルに対するアクセス要求を受信した場合（図２０（２））、アクセス要求の対象ファイルに対するロック情報を、共有メモリ領域２１２の引継ぎ情報に反映する（図２０（３））。そして、ＬＰＡＲ１において障害が発生したことをＬＰＡＲ２が認識すると、ＬＰＡＲ２は、共有メモリ領域２１２の引継ぎ必要情報を取得し、引継ぎ必要情報に基づいて、各種設定等を行う。これにより、ＬＰＡＲ２が、ＬＰＡＲ１による処理を引継いで実行する。このように、本実施例によると、共有メモリ領域２１２から引継ぎ必要情報を取得できるので、ＬＰＡＲ１で障害が発生した際に、迅速にフェールオーバすることができる。
　次に、実施例を詳細に説明する。
　図１は、計算機システムの構成図である。
　計算機システムは、複数（又は１つ）のクライアント８０と、複数のクライアント８０が接続された統合プラットフォーム装置１０とを有する。クライアント８０と、統合プラットフォーム装置１０とは、例えば、ＴＣＰ／ＩＰネットワーク等の通信ネットワークを介して接続されている。
　クライアント８０は、上位装置の一例であり、統合プラットフォーム装置１０に対して、ファイル単位でデータのアクセス（リード、ライト）を実行する計算機である。具体的には、クライアント８０は、統合プラットフォーム装置１０に対して、ファイルアクセス要求（ファイルのリード要求又はライト要求）を発行する。
　クライアント８０は、メモリ８１と、ＮＩＣ（Network　Interface　card）８３と、物理記憶デバイス（以下、ＰＤＥＶ）８４と、それらに接続されたＣＰＵ８２とを有する。メモリ８１は、ＣＰＵ８２で使用されるプログラムやデータを記憶する。ＣＰＵ８２は、メモリ８１に記憶されたプログラムを実行することにより、各種処理を実行する。ＮＩＣ８３は、他の装置（例えば、統合プラットフォーム装置１０）と接続するための通信インタフェースデバイスの一例である。ＰＤＥＶ８４は、例えば、ＨＤＤ（Hard　Disk　Drive）又はＳＳＤ(Solid　State　Drive)のような不揮発性の記憶デバイスである。ＰＤＥＶ８４は、ＣＰＵ８２で実行されるＯＳ（Operating　System）等のクライアント８０を制御するプログラム等を格納してよい。
　統合プラットフォーム装置１０は、サーバ部２０と、ストレージ部１１とを有する。サーバ部２０と、ストレージ部１１とは、内部データバス（例えば、ＰＣＩｅバス）４０を介して接続されている。
　サーバ部２０は、回路基板（例えばブレードサーバ）でよい。サーバ部２０は、メモリ２１と、ＮＩＣ２３と、内部Ｉ／Ｆ２４と、それらに接続されたＣＰＵ２２とを有する。メモリ２１は、例えば、ＤＲＡＭ（Dynamic　Random　Accesss　Memory）であり、ＣＰＵ２２が実行する各種プログラムやデータを記憶する。ＣＰＵ２２は、メモリ２１に格納された各種プログラムを実行することにより、各種処理を実行する。ＮＩＣ２３は、他の装置（例えば、クライアント８０）と接続するための通信インタフェースデバイスの一例である。サーバ部２０は、１又は複数のＯＳを実行し、ファイルサーバ機能の提供や、アプリケーションの実行を行う。内部Ｉ／Ｆ２４は、内部データバス４０を通じて通信するための通信インタフェースデバイスの一例である。サーバ部２０は、クライアント８０からのファイルアクセス要求を受信し、そのアクセス要求に基づくブロックＩ／Ｏ要求（アクセス対象のファイルを構成するデータブロックのＩ／Ｏ要求）をストレージ部１１に送信する。
　ストレージ部１１は、複数のＰＤＥＶ３１と、複数のＰＤＥＶ３１に接続されたＲＡＩＤ（Redundant　Array　of　Independent　(or　Inexpensive)　Disks）制御部３０とを有する。２以上のＰＤＥＶ３１によりＲＡＩＤグループが構成されていてよい。ＲＡＩＤグループに基づいてＬＵ（Logical　Unit）が構成される。ＲＡＩＤ制御部３０は、ＰＤＥＶ３１に対するアクセスを制御するモジュール（例えば回路基板）であり、内部データバス４０を通じて通信するための通信インタフェースデバイスと、メモリと、それらに接続されたＣＰＵとを有してよい。ＲＡＩＤ制御部３０は、サーバ部２０からブロックレベルのＩ／Ｏ要求を受信し、そのＩ／Ｏ要求に従い、ＰＤＥＶ３１に対するＩ／Ｏ処理（リード処理／ライト処理）を実行する。
　図２は、計算機システムのソフトウェアを含む構成図である。
　統合プラットフォーム装置１０は、クライアント８０に加えて管理計算機９０にも接続されている。管理計算機９０は、計算機システムの管理者が、計算機システムを管理するために用いる計算機であり、例えば、管理者から各種指示を受け付けて統合プラットフォーム装置１０に送信する。
　統合プラットフォーム装置１０では、メモリ２１上のハイパバイザ６０がＣＰＵ２２により実行される。ハイパバイザ６０は、統合プラットフォーム装置１０の物理リソース（メモリ２１、ＣＰＵ２２、ＮＩＣ２３等）を論理的に分割することにより得られた論理リソースを管理する。ハイパバイザ６０は、論理リソースが割り当てられたＬＰＡＲ５０を生成する。各ＬＰＡＲ５０でＯＳが実行されてよい。ハイパバイザ６０は、メモリ２１を論理的に分割することにより、ＬＰＡＲ１用のメモリ領域１、ＬＰＡＲ２用のメモリ領域２、及び、ＬＰＡＲ１及び２の共有メモリ領域２１２を用意する。共有メモリ領域２１２には、例えば、後述するクラスタ構成管理テーブル１００（図３参照）、引継ぎ情報管理テーブル１１０（図４参照）、及び障害監視管理テーブル１３０（図５参照）が管理される。
　ＣＰＵ２２を論理的に分割することにより、論理リソースとして、ＣＰＵ１及びＣＰＵ２が得られる。ＣＰＵ１は、ＬＰＡＲ１のＣＰＵ（ＬＰＡＲ１に割り当てられた論理リソース）であり、ＣＰＵ２は、ＬＰＡＲ２のＣＰＵである。
　ＬＰＡＲ５０は、ファイル共有プログラム５１と、ファイルシステム５２と、フェールオーバプログラム５３と、カーネル／ドライバ５４とを実行する。
　ファイル共有プログラム５１は、ＣＩＦＳ（Common　Internet　File　System）、ＮＦＳ（Network　File　System）等の通信プロトコルを使用して、複数のクライアント間でファイルを共有することのできるファイル共有サービスを提供する。
　ファイルシステム５２は、ＬＵ３１１上にファイルという管理単位を実現するために構築された論理構造を含む。本実施例では、ファイルシステム５２は、論理構造を管理するファイルシステムプログラムを含む。ファイルシステム５２は、論理構造として、スーパーブロック、ｉｎｏｄｅ管理テーブル、データブロックを含む。スーパーブロック、ｉｎｏｄｅ管理テーブル、及びデータブロックは、公知であるので、ここでは、簡単な説明に留める。スーパーブロックは、ファイルシステムの情報を一括保持する。例えば、スーパーブロックは、ファイルシステムの大きさ、ファイルシステムの空き容量等のファイルシステム全体の管理情報を保持する。ｉｎｏｄｅ管理テーブルは、個々のファイル／ディレクトリのメタ情報を管理する。ｉｎｏｄｅ管理テーブルは、ファイルについては、データブロックへのアドレスも管理する。なお、ファイルシステム５２の構造体は、ＬＵ３１１に格納されており、その構造体の一部又は全部がＬＰＡＲ用のメモリ領域に呼び出される。
　フェールオーバプログラム５３は、同一のクラスタの他のＬＰＡＲ５０の障害発生を監視し、障害を検知した場合には、障害元のＬＰＡＲ５０で稼働していたリソース（ＩＰアドレス、ファイルシステム等）を引継いで、障害元のＬＰＡＲ５０で実行していたファイル共有サービスを再開させるフェールオーバを実行する。
　カーネル／ドライバ５４は、統合プラットフォーム装置１０上で動作する複数のプログラム（プロセス）のスケジュールを制御したり、ハードウェアからの割込みをハンドリングしたりする等の全般的な制御及びハードウェア固有の制御を行うプログラムである。
　ＲＡＩＤ制御部３０は、ＲＡＩＤグループに基づくＬＵ３１１に対して入出力処理を実行する。
　図２に示すように、ＬＡＰＲ　ｎ（ｎ＝１又は２）が実行するプログラム、及び、ＬＰＡＲ　ｎに割り当てた論理リソースには、ＬＰＡＲと同じ番号ｎが割り振られている。以下、説明が冗長になることを避けるために、ＬＰＡＲ　ｎが実行するプログラム又はＬＰＡＲ　ｎに割り当てられた論理リソースを、参照符号に代えて番号ｎを使用して説明することがある。
　図３は、クラスタ構成管理テーブルの一例の構成図である。
　クラスタ構成管理テーブル１００は、相手ノード名称１００ａ、監視間隔１００ｂ、リソースグループ数１００ｃ、リソースグループ　１００ｄのフィールドを有する。
　相手ノード名称１００ａには、クラスタ構成となる相手のノード（ＬＰＡＲ）のノード名が格納される。監視間隔１００ｂには、障害監視を行う時間間隔が格納される。リソースグループ数１００ｃには、ＬＰＡＲにおけるファイル共有サービスを提供する上で必要なリソースをグループ化したリソースグループの数が格納される。リソースグループ　１００ｄの数は、リソースグループ数１００ｃに設定されたリソースグループの数以上である。リソースグループ　１００ｄには、リソースグループに関する情報（リソースグループ情報）、例えば、リソースグループに対してクライアント８０からアクセスするためのＩＰアドレスと、リソースグループに属するファイルシステムの数と、リソースグループに属する各ファイルシステムのファイルシステム名とが格納される。
　図４は、引継ぎ情報管理テーブルの一例の構成図である。
　引継ぎ情報管理テーブル１１０は、ＮＦＳ設定情報１１０ａと、ＣＩＦＳ設定情報１１０ｂと、ロック情報１１０ｃとのフィールドを有する。
　ＮＦＳ設定情報１１０ａ及びＣＩＦＳ設定情報１１０ｂには、それぞれ、公開先ＩＰアドレス、公開ｄｉｒ名、及びアクセス権が格納される。公開先ＩＰアドレスは、ファイルシステムを公開している計算機（クライアント等）のＩＰアドレスである。公開ｄｉｒ名は、公開しているディレクトリの名称である。公開しているディレクトリとしては、ファイルシステム内のディレクトリ、ファイルシステムのルートディレクトリ、又はグローバルネームスペースのルートディレクトリであっても良い。アクセス権は、公開先に対してどのようなアクセスが許可されているかを示す。アクセス権としては、リードのみ許可、リード及びライト許可等がある。
　ロック情報１１０ｃには、ファイル名及びＩＰアドレスが格納される。ファイル名は、ロック対象のファイルの名称である。ＩＰアドレスは、ファイル名のファイルをロックしている計算機（ロックオーナ）のＩＰアドレスである。
　本実施例の説明では、クラスタ構成管理テーブル１００に格納される情報全体を、「クラスタ構成情報」と呼び、引継ぎ情報管理テーブル１１０に格納される情報全体を、「引継ぎ情報」と呼ぶことがある。クラスタ構成管理テーブル１００及び引継ぎ情報管理テーブル１１０に設定されている情報が引継ぎ必要情報の一例である。
　図５は、障害監視管理テーブルの一例の構成図である。
　障害監視管理テーブル１２０は、カウンタ１　１２０ａと、カウンタ２　１２０ｂと、障害フラグ１２０ｃとのフィールドを有する。カウンタ１　１２０ａには、ＬＰＡＲ１によりカウントアップされるカウント値が格納される。カウンタ２　１２０ｂには、ＬＰＡＲ２によりカウントアップされるカウント値が格納される。カウント値は、カウントアップに代えてカウントダウン等の別の方法により更新されてもよい。カウント値が確認用情報の一例である。障害フラグ１２０ｃには、ＬＰＡＲに障害が発生したか否かを示すフラグ（障害フラグ）が格納される。障害フラグは、ハイパバイザ６０がＬＰＡＲの障害を検知した時にＯＮ（オン）に設定される。
　以下、本実施例で行われる処理を説明する。
　まず、初期処理を、図６及び図１１を参照して説明する。
　図６は、初期処理の模式図であり、図１１は、初期処理のフローチャートである。
　管理計算機９０は、管理者からＬＰＡＲ１についてのクラスタ構成情報及び引継ぎ情報の入力を受け付け、クラスタ構成要求の指示を受け付ける（図６（１））と、受け付けたクラスタ構成情報及び引継ぎ情報を統合プラットフォーム装置１０のＬＰＡＲ１に送信する（図６（２））。
　ＬＰＡＲ１のフェールオーバプログラム１は、管理計算機９０からクラスタ構成情報及び引継ぎ情報を受信し（図１１（Ｓ１１））、カーネル／ドライバ５４に対して、共有メモリ領域の確保要求を行う（図１１（Ｓ１２）、図６（３））。カーネル／ドライバ５４は、ハイパバイザ６０に対して、共有メモリ領域の確保要求を行う（図６（４））。共有メモリ領域の確保要求を受け取ったハイパバイザ６０は、メモリ２１から共有メモリ領域２１２を確保する（図６（５））。
　共有メモリ領域２１２が確保された後、フェールオーバプログラム１は、カーネル／ドライバ１を介して、共有メモリ領域２１２にクラスタ構成情報をクラスタ構成管理テーブル１００として登録し（図１１（Ｓ１３）、図６（６））、共有メモリ領域２１２に、引継ぎ情報を引継ぎ情報管理テーブル１１０として登録する（図１１（Ｓ１４）、図６（６））。なお、クラスタ構成情報の一部、及び、引継ぎ情報の一部、のうちの少なくとも一方が、共有メモリ領域２１２に代えて又は加えて、少なくとも１つのＬＵ３１１に格納されてもよい。
　その後、フェールオーバプログラム１は、障害監視処理（図８、図１５、図１６、及び図１７参照）を開始する（Ｓ１５）。
　次に、初期処理後の１つの処理である通常処理を、図７、図１２、及び図１３を参照して説明する。
　図７は、通常処理の模式図であり、図１２は、ファイルアクセス処理のフローチャートであり、図１３は、デステージ処理のフローチャートである。
　クライアント８０は、ユーザからファイルアクセス要求の指示を受け付ける（図７（１））と、受け付けたファイルアクセス要求をＬＰＡＲ１に送信する（図７（２））。
　ＬＰＡＲ１のファイル共有プログラム１は、クライアント８０からファイルアクセス要求を受信すると、ファイルアクセス要求がライト要求であるか、リード要求であるかを判定する（Ｓ２１）。この結果、ファイルアクセス要求がライト要求である場合（図１２（Ｓ２１：Ｙｅｓ））には、ファイル共有プログラム１は、ファイルアクセス要求に従うアクセス対象ファイルのロックを取得し、共有メモリ領域２１２の引継ぎ情報管理テーブル１１０に、取得したロックの内容を反映する（図１２（Ｓ２２）、図７（３））。ファイル共有プログラム１は、ファイルシステム１に対して、ファイルのライト要求を行う（図１２（Ｓ２３）、図７（４））。
　ファイルシステム１は、メモリ領域１（占有メモリ領域１）のファイルに対してライト要求に対応するライト処理を実行する（図１２（Ｓ２４）、図７（５））。なお、ファイルシステム５２は、図１３に示すように、メモリ領域１に十分な空きがあるか否かを判定し（図１３（Ｓ４１））、メモリ領域１に十分な空きがない場合（図１３（Ｓ４１：Ｎｏ））には、使用率の低いファイルをデステージする、すなわち、使用率の低いファイルをメモリ領域１からＬＵ３１１へ書き込む（図１３（Ｓ４２）、図７（６））。
　ファイルシステム１によるライト処理の実行後に、ファイル共有プログラム１は、要求元のクライアント８０に応答を返し（図１２（Ｓ２５））、ロックを解除し、共有メモリ領域２１２の引継ぎ情報管理テーブル１１０から、解除したロックの内容を削除し（図１２（Ｓ２６））、ファイルアクセス処理を終了する。
　一方、ファイルアクセス要求がリード要求である場合（図１２（Ｓ２１：Ｎｏ））には、ファイル共有プログラム１は、ファイルアクセス要求に従うアクセス対象のファイルのロックを取得し、共有メモリ領域２１２の引継ぎ情報管理テーブル１１０に、取得したロックの内容を反映する（図１２（Ｓ２７）、図７（３））。ファイル共有プログラム５１は、ファイルシステム５２に対して、ファイルのリード要求を行う（図１２（Ｓ２８）、図７（４））。
　ファイルシステム１は、メモリ領域１（占有メモリ領域１）のファイルに対してリード要求に対応するリード処理を実行する（図１２（Ｓ２９）、図７（５））。
　ファイルシステム１によるリード処理の実行後に、ファイル共有プログラム１は、要求元のクライアント８０に取得したファイルを返し（図１２（Ｓ３０））、ロックを解除し、共有メモリ領域２１２の引継ぎ情報管理テーブル１１０から、解除したロックの内容を削除し（図１２（Ｓ３１））、ファイルアクセス処理を終了する。
　次に、障害監視処理を、図８、図９、図１５、図１６、及び図１７を参照して説明する。
　図８は、障害監視処理の一部分の模式図であり、図９は、障害監視処理の残り部分の模式図であり、図１５は、カウンタ更新処理のフローチャートであり、図１６は、障害確認処理及びフェールオーバ処理のフローチャートであり、図１７は、カウンタ監視処理のフローチャートである。
　図８に示すように、フェールオーバプログラム１及び２は、障害監視管理テーブル１２０のそれぞれのＬＰＡＲに対応するカウンタの値を所定の時間毎に更新する（図８（１）、図１５（Ｓ５１））。
　一方、ハイパバイザ６０は、障害監視管理テーブル１２０のそれぞれのＬＰＡＲに対応するカウンタの値を確認し（図８（２）、図１７（Ｓ８１））、各カウンタが一定期間内に更新されたか否かを判定する（図１７（Ｓ８２））。この結果、更新されている場合（Ｓ８２：Ｙｅｓ）には、ハイパバイザ６０は、処理をＳ８１に進め、更新されていない場合（Ｓ８２：Ｎｏ）には、障害監視管理テーブル１２０の障害フラグ１２０ｃの値をＯＮに設定する（図８（３）、図１７（Ｓ８３））。ＬＰＡＲに障害が発生していることを通知するためである。
　次に、フェールオーバプログラム１（２）は、カーネル／ドライバ１（２）及びハイパバイザ６０を介して、共有メモリ領域２１２の障害監視管理テーブル１２０の障害フラグ１２０ｃの値を監視する（図９（１）、図１６（Ｓ６１））。
　フェールオーバプログラム１（２）は、障害が発生しているか否かを判定する（Ｓ６２）。具体的には、フェールオーバプログラム１（２）は、共有メモリ領域２１２の障害監視管理テーブル１２０の障害フラグ１２０ｃの値がＯＮである場合には、障害が発生していると判定する。この結果、障害が発生していない場合（図１６（Ｓ６２：Ｎｏ））には、フェールオーバプログラム１（２）は、処理をＳ６１に進め、障害が発生している場合（Ｓ６２：Ｙｅｓ）には、後述するフェールオーバ処理（Ｓ６３～Ｓ６７）を実行する。
　ここで、障害が発生した場合を例に計算機システムの動作を説明する。
　図１４は、障害監視処理及びフェールオーバ処理のシーケンス図である。
　ＬＰＡＲ１及びＬＰＡＲ２においても障害が発生していない場合には、図１５に示すカウンタ更新処理のＳ５１により、フェールオーバプログラム１は、障害監視管理テーブル１２０のカウント値１（カウンタ１　１２０ａのカウント値）を所定の時間毎に更新し（図１４（１））、フェールオーバプログラム２は、障害監視管理テーブル１２０のカウント値２（ＬＰＡＲ２に対応するカウンタ２　１２０ｂのカウント値）を所定の時間毎に更新する（図１４（２））。この結果、ハイパバイザ６０によるカウンタ監視処理（図１７）においては、障害監視管理テーブル１２０の障害フラグ１２０ｃの値は、ＯＮに設定されない（図１４（３））。
　しかし、ＬＰＡＲ１において障害が発生すると、フェールオーバプログラム１は、カウンタ更新処理のＳ５１により、カウント値１を更新することができなくなる（図１４（４））。この結果、以降に行われるカウンタ監視処理（図１７）において、カウント値１が一定期間更新されていないことが検出され、障害監視管理テーブル１２０の障害フラグ１２０ｃの値が、ＯＮに設定されることとなる（図１４（５））。
　この後、ＬＰＡＲ２のフェールオーバプログラム２が、図１６に示す障害確認処理及びフェールオーバ処理を実行すると、障害監視管理テーブル１２０の障害フラグ１２０ｃの値がＯＮに設定されているので、Ｓ６２で障害が発生していると判定され、後続のフェールオーバ処理（Ｓ６３～Ｓ６７）が実行される（図１４（６））。
　次に、ＬＰＡＲに障害が発生している場合におけるフェールオーバ処理を図１０及び図１６を参照して説明する。障害が発生した一方のＬＰＡＲをＬＰＡＲ１とし、他方のＬＰＡＲをＬＰＡＲ２とする。
　ＬＰＡＲ１において障害が発生したことを検出したフェールオーバプログラム２は、カーネル／ドライバ２及びハイパバイザ６０を介して、共有メモリ領域２１２のクラスタ構成管理テーブル１００からリソースグループ情報（具体的には、クラスタ構成管理テーブル１００のリソースグループ　１００ｄに設定されている情報）を取得する（図１０（１）、図１６（Ｓ６３））。次に、フェールオーバプログラム２は、リソースグループ情報から特定されるファイルシステムをチェックし、そのファイルシステムをＬＰＡＲ２にマウントする（図１０（２）、図１６（Ｓ６４））。これにより、ＬＰＡＲ２は、ＬＰＡＲ１が使用していたファイルシステムを使用できるようになる。
　次に、フェールオーバプログラム５３は、リソースグループ情報に含まれているＩＰアドレスをＬＰＡＲ２のＩＰアドレスに設定する（図１０（３）、図１６（Ｓ６５））。これにより、ＬＰＡＲ２は、ＬＰＡＲ１がクライアント８０から受信していたアクセス要求を受信できるようになる。
　次に、フェールオーバプログラム２は、カーネル／ドライバ２及びハイパバイザ６０を介して、共有メモリ領域２１２の引継ぎ情報管理テーブル１１０から引継ぎ情報（具体的には、引継ぎ情報管理テーブル１１０のＮＦＳ設定情報１１０ａ、ＣＩＦＳ設定情報１１０ｂ、ロック情報１１０ｃに設定された情報）を取得し、取得した情報に基づいて、ファイル共有プログラム２を設定し（図１０（４）、図１６（Ｓ６６））、ファイル共有プログラム２による動作を再開してクライアント８０からのアクセス要求を受け付け可能とする（図１０（５））。
　このように、ＮＦＳ設定情報１１０ａ、ＣＩＦＳ設定情報１１０ｂ、ロック情報１１０ｃに設定された情報に基づいてファイル共有プログラム２を設定するので、ファイル共有プログラム２を、ＬＰＡＲ１におけるファイル共有プログラム１の使用状態と同じ状態としてファイル共有サービスを提供できる。例えば、ＬＰＡＲ１においてファイルシステムを公開していたクライアント８０に対して、同様のアクセス権のファイル共有サービスを提供することができる。また、ＬＰＡＲ１においてファイルシステムを使用していた場合におけるロックの状態を維持することができる。したがって、或るクライアント８０からのファイルアクセス要求によって或るファイルに対してロックがかけられた状態において、ＬＰＡＲ１に障害が発生した場合であっても、ＬＰＡＲ２において、そのロックの状態を引継ぐことができるので、ロックされていたファイルが他のクライアント８０により占有されることを防止でき、クライアント８０に対してファイルアクセスを継続させることができる。
　次に、フェールオーバプログラム２は、障害の発生したＬＰＡＲ１をリセットするリセット処理（図１６（Ｓ７１～Ｓ７３））を行う（図１６（Ｓ６４））。なお、このリセット処理を実行するにあたっては、障害の発生したＬＰＡＲ１のメモリ領域１のデータをクリア（消去）しないようにしている。
　リセット処理では、フェールオーバプログラム２は、障害の発生したＬＰＡＲ１のメモリ領域１中の未使用領域にＯＳをロードし、ＯＳを起動する（図１６（Ｓ７１））。
　次に、フェールオーバプログラム２は、カーネル／ドライバ２及びハイパバイザ６０を介して、障害の発生したＬＰＡＲ１のメモリ領域１中の実際に使用されている領域のデータを読込み（図１６（Ｓ７２））、読込んだデータをファイルとして出力する（図１６（Ｓ７３））。これにより、障害の発生したＬＰＡＲ１が使用していたメモリ領域１の情報を適切にファイルにすることができる。
　次に、計算機システムにおける一部の処理をより詳細に説明する。
　図１８は、共有メモリ領域へのアクセスを説明するシーケンス図である。図１８に示すシーケンスは、図１１に示すＳ１２乃至Ｓ１４の処理、図１６のＳ６３及びＳ６６の処理に関連する。
　まず、共有メモリ領域を確保する処理（Ｓ１２）に関わる処理について説明する。
　ＬＰＡＲ１のフェールオーバプログラム１は、ハイパバイザ６０に対してサイズを指定して共有メモリ領域確保要求を送信する（Ｓ９１）。ここで指定するサイズとしては、例えば、クラスタ構成管理テーブル１００、引継ぎ情報管理テーブル１１０、及び障害監視管理テーブル１２０の初期サイズと、運用開始後に増加すると考えられる引継ぎ情報管理テーブル１１０の増加分とを考慮したサイズである。ハイパバイザ６０は、共有メモリ領域確保要求を受信すると、要求に従ったサイズの共有メモリ領域２１２の領域を確保する（Ｓ９２）。次に、ハイパバイザ６０は、ＬＰＡＲ１に対して、共有メモリ領域２１２を一意に識別するためのハンドルを送信する（Ｓ９３）。ここで、ハンドルには、例えば、共有メモリ領域確保要求を行ったＬＰＡＲ１のＩＤと、メモリ領域２１における共有メモリ領域２１２の先頭アドレスとが含まれる。
　次に、確保した共有メモリ領域２１２にデータを格納する処理（Ｓ１３）に関わる処理について説明する。
　ＬＰＡＲ１は、共有メモリ領域２１２にデータを格納する際には、受信したハンドル、書き込むデータのサイズであるオフセット、及びデータを含むライト要求をハイパバイザ６０に送信する（Ｓ９４）。ハイパバイザ６０は、ライト要求に従って共有メモリ領域２１２にデータを格納し（Ｓ９５）、ライト要求の処理結果をＬＰＡＲ１に送信する（Ｓ９６）。
　ＬＰＡＲ１は、共有メモリ領域２１２にアクセスするためのハンドルをＬＰＡＲ２に送信する（Ｓ９７）。ＬＰＡＲ２のフェールオーバプログラム２は、共有メモリ領域にアクセスするためのハンドルをＬＰＡＲ２のメモリ領域２に格納する（Ｓ９８）。このハンドルにより、ＬＰＡＲ２は、確保された共有メモリ領域２１２に対して適切にアクセスすることができる。
　次に、共有メモリ領域２１２に格納されたデータをＬＰＡＲ２で読み出す処理（Ｓ６３、Ｓ６６）に関わる処理について説明する。
　共有メモリ領域２１２からデータを読み出す必要がある場合（Ｓ６３、Ｓ６６）には、ＬＰＡＲ２のフェールオーバプログラム２は、ＬＰＡＲ２のメモリ領域２に格納しているハンドルと、読み出すデータのサイズを示すオフセットとを含むリード要求をハイパバイザ６０に送信する（Ｓ９９）。ハイパバイザ６０は、リード要求に従って共有メモリ領域２１２からデータを読み出し（Ｓ１００）、読み出したデータをＬＰＡＲ２に送信する（Ｓ１０１）。
　このように、共有メモリ領域２１２を必要な時点で確保し、共有メモリ領域２１２を特定することのできるハンドルをＬＰＡＲ２に渡すようにしているので、共有メモリ領域２１２を予め用意しておく必要がない。
　図１９は、メモリダンプ処理のシーケンス図である。図１９に示すシーケンスは、主に、図１６のＳ７２及びＳ７３に関わる各構成の処理に対応する。
　Ｓ７２においては、ＬＰＡＲ２のフェールオーバプログラム２は、ハイパバイザ６０に対してＬＰＡＲ１のメモリ領域１（占有メモリ領域１）の情報の取得要求を送信する（Ｓ１１１）。ハイパバイザ６０は、占有メモリ領域１の情報の取得要求に従って占有メモリ領域１にアクセスし（Ｓ１１２）、ＬＰＡＲ１の占有メモリ領域情報を取得する（Ｓ１１３）。ここで、ハイパバイザ６０は、ＬＰＡＲ１のメモリ領域１の状態を把握しており、且つＬＰＡＲ１に障害が発生し、占有メモリ領域１を使用することはないので、排他制御を行うことなく容易にＬＰＡＲ１の占有メモリ領域情報を取得することができる。次に、ハイパバイザ６０は、取得した占有メモリ領域情報を、ＬＰＡＲ２に返却する（Ｓ１１４）。ハイパバイザ６０から占有メモリ領域情報の返却を受けたＬＰＡＲ２のフェールオーバプログラム２は、占有メモリ領域情報をＰＤＥＶへ書き出す（Ｓ７３）。これにより、ＬＰＡＲ１に障害が発生していても、適切にＬＰＡＲ１の占有メモリ領域１の情報を回収することができ、障害の解析等を適切に行うことができる。
　以上、一実施例を説明したが、本発明は、この実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、ＬＰＡＲに障害が発生したことを、ハイパバイザ６０が直接的に他のＬＰＡＲのフェールオーバプログラム５３に通知するようにしても良い。
　１０：統合プラットフォーム装置　２０：サーバ部　３０：ＲＡＩＤ制御部　８０：クライアント　９０：管理計算機

Claims (12)

  1. 　上位装置に接続された通信インタフェースと、メモリと、それらに接続されたプロセッサとを含んだ物理リソースと、
    　前記物理リソースを論理的に分割することにより得られた第１及び第２論理リソースがそれぞれ割り当てられた第１及び第２論理区画を管理する仮想化機構と
    を有し、
    　前記第１及び第２論理区画は、それぞれ、前記記憶デバイスに対するデータ入出力処理を実行可能であり、
    　前記仮想化機構が、前記メモリに基づく領域であり前記第１及び第２論理区画がアクセス可能な共有メモリ領域を提供し、
    　前記第１論理区画は、前記共有メモリ領域に対して、前記第１論理区画が担当しているデータ入出力処理を前記第２論理区画に引継ぐために必要な引継ぎ必要情報を格納し、
    　前記第２論理区画は、前記第１論理区画における障害の発生を検出した場合に、前記共有メモリ領域から前記引継ぎ必要情報を取得し、前記引継ぎ必要情報に基づいて、前記第１論理区画が担当していた前記データ入出力処理を引継いで実行する、
    ストレージ装置。
  2. 　前記仮想化機構は、前記第１論理区画に障害が発生したか否かを監視し、障害が発生した場合に、前記第１論理区画に障害が発生したことを前記第２論理区画が認識できるようにする、
    請求項１記載のストレージ装置。
  3. 　前記第１論理区画は、正常動作時には、所定の時間間隔で正常動作していることを示す確認用情報を前記共有メモリ領域に書込み、
    　前記仮想化機構は、前記共有メモリ領域の前記確認用情報を確認することにより、前記第１論理区画に障害が発生したか否かを判定する、
    請求項２記載のストレージ装置。
  4. 　前記第１論理区画は、前記仮想化機構から前記共有メモリ領域の割当てを受け、割当てられた前記共有メモリ領域に対して、前記引継ぎ必要情報を書込む、
    請求項１記載のストレージ装置。
  5. 　前記第１論理区画は、前記第２論理区画に対して、割当てられた前記前記共有メモリ領域を特定可能なハンドルを送信し、
    　前記第２論理区画は、前記第１論理区画に障害が発生したことを認識した場合に、前記ハンドルを用いて、前記共有メモリ領域にアクセスして前記引継ぎ必要情報を取得する、
    請求項４記載のストレージ装置。
  6. 　前記第１論理区画及び前記第２論理区画は、前記仮想化機構を介して前記共有メモリ領域にアクセスする、
    請求項１記載のストレージ装置。
  7. 　前記第１論理区画は、ファイルシステムを有し、前記ファイルシステムを用いて、前記上位装置から要求されたファイルのデータ入出力処理を実行し、
    　前記引継ぎ必要情報は、前記第１論理区画が有する前記ファイルシステムを特定する情報を含む、
    請求項１記載のストレージ装置。
  8. 　前記引継ぎ必要情報は、前記上位装置が前記ファイルシステムにアクセスするためのアドレス情報を更に含む、
    請求項７記載のストレージ装置。
  9. 　前記引継ぎ必要情報は、前記ファイルシステムにアクセス可能な上位装置を示す識別情報を更に含む、
    請求項８記載のストレージ装置。
  10. 　前記引継ぎ必要情報は、前記ファイルシステムにアクセス可能な上位装置に関するアクセス権限を示す情報を更に含む、
    請求項９記載のストレージ装置。
  11. 　前記引継ぎ必要情報は、前記ファイルシステムのファイルのロックに関する情報を含み、
    　前記第１論理区画は、前記上位装置からファイルに対するアクセス要求を受け付けた場合に、前記ファイルのロックに関する情報を、前記引継ぎ必要情報に反映する、
    請求項１記載のストレージ装置。
  12. 　上位装置に接続された通信インタフェースと、メモリと、それらに接続されたプロセッサとを含んだ物理リソースを論理的に分割することにより得られた第１及び第２論理リソースがそれぞれ割り当てられた第１及び第２論理区画に対し、前記メモリに基づく領域であり前記第１及び第２論理区画がアクセス可能な共有メモリ領域を提供し、
    　前記第１論理区画は、前記共有メモリ領域に対して、前記第１論理区画が担当しているデータ入出力処理を前記第２論理区画に引継ぐために必要な引継ぎ必要情報を格納し、
    　前記第２論理区画は、前記第１論理区画における障害の発生を検出した場合に、前記共有メモリ領域から前記引継ぎ必要情報を取得し、前記引継ぎ必要情報に基づいて、前記第１論理区画が担当していた前記データ入出力処理を引継いで実行する、
    フェールオーバ方法。

     
PCT/JP2013/077783 2013-10-11 2013-10-11 ストレージ装置及びフェールオーバ方法 WO2015052836A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/371,147 US9262289B2 (en) 2013-10-11 2013-10-11 Storage apparatus and failover method
PCT/JP2013/077783 WO2015052836A1 (ja) 2013-10-11 2013-10-11 ストレージ装置及びフェールオーバ方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/077783 WO2015052836A1 (ja) 2013-10-11 2013-10-11 ストレージ装置及びフェールオーバ方法

Publications (1)

Publication Number Publication Date
WO2015052836A1 true WO2015052836A1 (ja) 2015-04-16

Family

ID=52812683

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/077783 WO2015052836A1 (ja) 2013-10-11 2013-10-11 ストレージ装置及びフェールオーバ方法

Country Status (2)

Country Link
US (1) US9262289B2 (ja)
WO (1) WO2015052836A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017052548A1 (en) 2015-09-24 2017-03-30 Hewlett Packard Enterprise Development Lp Failure indication in shared memory

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9990258B2 (en) * 2014-01-31 2018-06-05 Hitachi, Ltd. Management computer and management program
US9983917B2 (en) 2015-11-30 2018-05-29 International Business Machines Corporation Monitoring and responding to operational conditions of a logical partition from a separate logical partition
US20180150331A1 (en) * 2016-11-30 2018-05-31 International Business Machines Corporation Computing resource estimation in response to restarting a set of logical partitions
US11132230B2 (en) * 2019-07-15 2021-09-28 International Business Machines Corporation Managing quality of service in a network file share environment
US10990488B1 (en) * 2019-12-12 2021-04-27 Dell Products L.P. System and method for reducing failover times in a redundant management module configuration

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004021608A (ja) * 2002-06-17 2004-01-22 Nec Corp 二重化サーバの障害検知方式及びその方法
JP2004234558A (ja) * 2003-01-31 2004-08-19 Hitachi Ltd 記憶デバイス制御装置、及びプログラム
JP2007207219A (ja) * 2006-01-06 2007-08-16 Hitachi Ltd 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム
JP2007279890A (ja) * 2006-04-04 2007-10-25 Hitachi Ltd バックアップシステム及びバックアップ方法
JP2013045444A (ja) * 2011-08-19 2013-03-04 Hitachi Ltd データセンタ内のリソースの使用効率を改善するための方法及び装置

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050198636A1 (en) * 2004-02-26 2005-09-08 International Business Machines Corporation Dynamic optimization of batch processing
US7530071B2 (en) * 2004-04-22 2009-05-05 International Business Machines Corporation Facilitating access to input/output resources via an I/O partition shared by multiple consumer partitions
US7937616B2 (en) * 2005-06-28 2011-05-03 International Business Machines Corporation Cluster availability management
JP5068056B2 (ja) * 2006-10-11 2012-11-07 株式会社日立製作所 障害回復方法、計算機システム及び管理サーバ
JP4809209B2 (ja) * 2006-12-28 2011-11-09 株式会社日立製作所 サーバ仮想化環境における系切り替え方法及び計算機システム
JP4874847B2 (ja) 2007-03-27 2012-02-15 株式会社東芝 クラスタシステム
JP4744480B2 (ja) 2007-05-30 2011-08-10 株式会社日立製作所 仮想計算機システム
US8230077B2 (en) * 2008-06-06 2012-07-24 International Business Machines Corporation Hypervisor-based facility for communicating between a hardware management console and a logical partition
JP4572250B2 (ja) * 2008-09-11 2010-11-04 株式会社日立製作所 計算機切り替え方法、計算機切り替えプログラム及び計算機システム
US20110154133A1 (en) * 2009-12-22 2011-06-23 International Business Machines Corporation Techniques for enhancing firmware-assisted system dump in a virtualized computer system employing active memory sharing
JP5548647B2 (ja) * 2011-04-25 2014-07-16 株式会社日立製作所 計算機システムでの部分障害処理方法
US9817733B2 (en) * 2011-10-05 2017-11-14 International Business Machines Corporation Resource recovery for checkpoint-based high-availability in a virtualized environment
US8880934B2 (en) * 2012-04-04 2014-11-04 Symantec Corporation Method and system for co-existence of live migration protocols and cluster server failover protocols
US8930507B2 (en) * 2012-06-12 2015-01-06 International Business Machines Corporation Physical memory shared among logical partitions in a VLAN
JP5422705B2 (ja) 2012-07-06 2014-02-19 株式会社日立製作所 仮想計算機システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004021608A (ja) * 2002-06-17 2004-01-22 Nec Corp 二重化サーバの障害検知方式及びその方法
JP2004234558A (ja) * 2003-01-31 2004-08-19 Hitachi Ltd 記憶デバイス制御装置、及びプログラム
JP2007207219A (ja) * 2006-01-06 2007-08-16 Hitachi Ltd 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム
JP2007279890A (ja) * 2006-04-04 2007-10-25 Hitachi Ltd バックアップシステム及びバックアップ方法
JP2013045444A (ja) * 2011-08-19 2013-03-04 Hitachi Ltd データセンタ内のリソースの使用効率を改善するための方法及び装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017052548A1 (en) 2015-09-24 2017-03-30 Hewlett Packard Enterprise Development Lp Failure indication in shared memory
EP3271820A4 (en) * 2015-09-24 2018-12-19 Hewlett-Packard Enterprise Development LP Failure indication in shared memory
US10613949B2 (en) 2015-09-24 2020-04-07 Hewlett Packard Enterprise Development Lp Failure indication in shared memory

Also Published As

Publication number Publication date
US9262289B2 (en) 2016-02-16
US20150301913A1 (en) 2015-10-22

Similar Documents

Publication Publication Date Title
US11360679B2 (en) Paging of external memory
US9733848B2 (en) Method and system for pooling, partitioning, and sharing network storage resources
US9733958B2 (en) Mechanism for performing rolling updates with data unavailability check in a networked virtualization environment for storage management
US20160378355A1 (en) Method and system for implementing performance tier de-duplication in a virtualization environment
EP3799396A1 (en) Provisioning and allocation of external memory
US20200371700A1 (en) Coordinated allocation of external memory
WO2015052836A1 (ja) ストレージ装置及びフェールオーバ方法
CN107710160B (zh) 计算机和存储区域管理方法
WO2014051639A1 (en) Storage architecture for server flash and storage array operation
US20240053886A1 (en) File operations in a distributed storage system
US11822445B2 (en) Methods and systems for rapid failure recovery for a distributed storage system
WO2011111249A1 (ja) 仮想計算機システム及び仮想計算機の制御方法
US20230127166A1 (en) Methods and systems for power failure resistance for a distributed storage system
US11693738B2 (en) Storage system spanning multiple failure domains
CN109416620B (zh) 存储集群
US8055867B2 (en) Methods, apparatuses, and computer program products for protecting pre-staged provisioned data in a storage system
Krogh et al. Configuration

Legal Events

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

Ref document number: 14371147

Country of ref document: US

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

Ref document number: 13895241

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13895241

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP