WO2015052836A1 - ストレージ装置及びフェールオーバ方法 - Google Patents
ストレージ装置及びフェールオーバ方法 Download PDFInfo
- 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
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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Hardware Redundancy (AREA)
Abstract
ストレージ装置は、ストレージ装置の物理リソースを論理的に分割することにより得られた第1及び第2論理リソースがそれぞれ割り当てられた第1及び第2LPAR(論理区画)を管理する仮想化機構を有する。仮想化機構は、メモリに基づく領域であり第1及び第2LPARがアクセス可能な共有メモリ領域を提供する。第1LPARは、共有メモリ領域に対して、第1LPARが担当しているデータ入出力処理を第2LPARに引継ぐために必要な引継ぎ必要情報を格納する。第2LPARは、第1LPARにおける障害の発生を検出した場合に、共有メモリ領域から引継ぎ必要情報を取得し、引継ぎ必要情報に基づいて、第1LPARが担当していたデータ入出力処理を引継いで実行する。
Description
本発明は、複数の論理区画(LPAR:Logical Partition)間のフェールオーバに関する。
ネットワークを構成する要素は一般にノードと呼ばれるが、複数のノード(例えば、サーバマシン)を連結したクラスタが知られている。ここで、クラスタとは、外部の装置に対して全体で1台のノード(装置)であるかのように振る舞うシステムをいう。クラスタでは、一般に、いずれかのノードに障害が発生した場合に、他のノードが処理やデータを引き継ぐフェールオーバが実行される。
フェイルオーバに関して、例えば、フェールオーバ発生時であっても、ディスクI/O性能劣化を抑えながら、トランザクションの整合を図る技術が知られている(例えば、特許文献1参照)。また、物理計算機上のLPARに障害が発生した場合に、他の物理計算機に交替先のLPARを設定して、LPAR単位の交替を可能にする技術も知られている(例えば、特許文献2参照)。
複数のLPARを実行可能なストレージ装置では、いずれかのLPARに障害が発生した場合に迅速に他のLPARにフェールオーバすることが望ましい。
ストレージ装置は、ストレージ装置の物理リソースを論理的に分割することにより得られた第1及び第2論理リソースがそれぞれ割り当てられた第1及び第2LPAR(論理区画)を管理する仮想化機構を有する。仮想化機構は、メモリに基づく領域であり第1及び第2LPARがアクセス可能な共有メモリ領域を提供する。第1LPARは、共有メモリ領域に対して、第1LPARが担当しているデータ入出力処理を第2LPARに引継ぐために必要な引継ぎ必要情報を格納する。第2LPARは、第1LPARにおける障害の発生を検出した場合に、共有メモリ領域から引継ぎ必要情報を取得し、引継ぎ必要情報に基づいて、第1LPARが担当していたデータ入出力処理を引継いで実行する。
迅速にLPAR間のフェールオーバを実行することができる。
以下、図面を参照して一実施例を説明する。
なお、以下の説明では「aaaテーブル」等の表現にて情報を説明する場合があるが、情報は、テーブル等のデータ構造以外で表現されていてもよい。データ構造に依存しないことを示すために「aaaテーブル」等について「aaa情報」と呼ぶことができる。
また、以下の説明では、プログラムを主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit))によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又は通信インタフェースを用いながら行うため、処理の主語が、プロセッサとされても良い。また、プロセッサが、処理の一部又は全部を行うハードウェア回路を含んでも良い。コンピュータプログラムは、プログラムソースから計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機が読み取り可能な記憶メディアであっても良い。
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号を使用し、同種の要素を区別して説明する場合には、参照符号に代えて要素に割り振られた識別番号を使用することがある。
また、以下の説明における用語の意味は、下記の通りである。
(*)「LPAR」は、論理区画(Logical Partition)の略であり、物理リソースを論理的に分割することにより得られた論理リソースが割り当てられた仮想マシンである。LPARは、外部の装置(例えばクライアント)に1つの装置として認識される。
(*)「ハイパバイザ」は、LPARを生成して稼働さる仮想化機構の一種である。
(*)「ノード」は、ネットワークを構成する要素を意味する。本実施例では、ノードは、クラスタの構成要素であるLPARである。
(*)「クラスタ」は、複数のノードで構成され外部の装置(例えばクライアント)に対して全体で1台のノード(装置)であるかのように振る舞うシステムである。
(*)「フェールオーバ」は、第1装置に障害が発生した場合に第2装置が処理やデータを引き継ぐこと、またはその機能を意味する。第1装置及び第2装置は、それぞれ、物理的な装置であっても、論理的な装置であっても良い。本実施例では、第1及び第2装置のいずれもLPARである。
(*)「LPAR」は、論理区画(Logical Partition)の略であり、物理リソースを論理的に分割することにより得られた論理リソースが割り当てられた仮想マシンである。LPARは、外部の装置(例えばクライアント)に1つの装置として認識される。
(*)「ハイパバイザ」は、LPARを生成して稼働さる仮想化機構の一種である。
(*)「ノード」は、ネットワークを構成する要素を意味する。本実施例では、ノードは、クラスタの構成要素であるLPARである。
(*)「クラスタ」は、複数のノードで構成され外部の装置(例えばクライアント)に対して全体で1台のノード(装置)であるかのように振る舞うシステムである。
(*)「フェールオーバ」は、第1装置に障害が発生した場合に第2装置が処理やデータを引き継ぐこと、またはその機能を意味する。第1装置及び第2装置は、それぞれ、物理的な装置であっても、論理的な装置であっても良い。本実施例では、第1及び第2装置のいずれもLPARである。
まず、図20を参照して、実施例に係る計算機システムの概要を説明する。
計算機システムが、ストレージ装置の一例でありクライアント80に接続された統合プラットフォーム装置10を有する。統合プラットフォーム装置10において、ハイパバイザ60によって生成された複数のLPAR50が動作する。ハイパバイザ60は、メモリを含む物理リソースが論理的に分割されることにより得られた複数の論理リソースと、複数の論理リソースの各々の割当先LPARを管理する。LPAR50として、LPAR1及び2がある。メモリを論理的に分割することにより、論理リソースとして、メモリ領域1、メモリ領域2及び共有メモリ領域212が得られる。LPAR1に、メモリ領域1が割り当てられ、LPAR2に、メモリ領域2が割り当てられる。また、LPAR1及び2に、LPAR1及び2のいずれもアクセス可能な共有メモリ領域が割り当てられる。
LPAR1が、LPAR1の動作をLPAR2に引継ぐ引継ぎ必要情報を、共有メモリ領域212に格納する(図20(1))。ここで、引継ぎ必要情報としては、例えば、LPAR1におけるリソースグループに関する情報、ファイルシステムにおける設定情報、ファイルシステムにおけるファイルのロックに関する情報(ロック情報)等がある。LPAR1は、クライアント80からファイルに対するアクセス要求を受信した場合(図20(2))、アクセス要求の対象ファイルに対するロック情報を、共有メモリ領域212の引継ぎ情報に反映する(図20(3))。そして、LPAR1において障害が発生したことをLPAR2が認識すると、LPAR2は、共有メモリ領域212の引継ぎ必要情報を取得し、引継ぎ必要情報に基づいて、各種設定等を行う。これにより、LPAR2が、LPAR1による処理を引継いで実行する。このように、本実施例によると、共有メモリ領域212から引継ぎ必要情報を取得できるので、LPAR1で障害が発生した際に、迅速にフェールオーバすることができる。
次に、実施例を詳細に説明する。
図1は、計算機システムの構成図である。
計算機システムは、複数(又は1つ)のクライアント80と、複数のクライアント80が接続された統合プラットフォーム装置10とを有する。クライアント80と、統合プラットフォーム装置10とは、例えば、TCP/IPネットワーク等の通信ネットワークを介して接続されている。
クライアント80は、上位装置の一例であり、統合プラットフォーム装置10に対して、ファイル単位でデータのアクセス(リード、ライト)を実行する計算機である。具体的には、クライアント80は、統合プラットフォーム装置10に対して、ファイルアクセス要求(ファイルのリード要求又はライト要求)を発行する。
クライアント80は、メモリ81と、NIC(Network Interface card)83と、物理記憶デバイス(以下、PDEV)84と、それらに接続されたCPU82とを有する。メモリ81は、CPU82で使用されるプログラムやデータを記憶する。CPU82は、メモリ81に記憶されたプログラムを実行することにより、各種処理を実行する。NIC83は、他の装置(例えば、統合プラットフォーム装置10)と接続するための通信インタフェースデバイスの一例である。PDEV84は、例えば、HDD(Hard Disk Drive)又はSSD(Solid State Drive)のような不揮発性の記憶デバイスである。PDEV84は、CPU82で実行されるOS(Operating System)等のクライアント80を制御するプログラム等を格納してよい。
統合プラットフォーム装置10は、サーバ部20と、ストレージ部11とを有する。サーバ部20と、ストレージ部11とは、内部データバス(例えば、PCIeバス)40を介して接続されている。
サーバ部20は、回路基板(例えばブレードサーバ)でよい。サーバ部20は、メモリ21と、NIC23と、内部I/F24と、それらに接続されたCPU22とを有する。メモリ21は、例えば、DRAM(Dynamic Random Accesss Memory)であり、CPU22が実行する各種プログラムやデータを記憶する。CPU22は、メモリ21に格納された各種プログラムを実行することにより、各種処理を実行する。NIC23は、他の装置(例えば、クライアント80)と接続するための通信インタフェースデバイスの一例である。サーバ部20は、1又は複数のOSを実行し、ファイルサーバ機能の提供や、アプリケーションの実行を行う。内部I/F24は、内部データバス40を通じて通信するための通信インタフェースデバイスの一例である。サーバ部20は、クライアント80からのファイルアクセス要求を受信し、そのアクセス要求に基づくブロックI/O要求(アクセス対象のファイルを構成するデータブロックのI/O要求)をストレージ部11に送信する。
ストレージ部11は、複数のPDEV31と、複数のPDEV31に接続されたRAID(Redundant Array of Independent (or Inexpensive) Disks)制御部30とを有する。2以上のPDEV31によりRAIDグループが構成されていてよい。RAIDグループに基づいてLU(Logical Unit)が構成される。RAID制御部30は、PDEV31に対するアクセスを制御するモジュール(例えば回路基板)であり、内部データバス40を通じて通信するための通信インタフェースデバイスと、メモリと、それらに接続されたCPUとを有してよい。RAID制御部30は、サーバ部20からブロックレベルのI/O要求を受信し、そのI/O要求に従い、PDEV31に対するI/O処理(リード処理/ライト処理)を実行する。
図2は、計算機システムのソフトウェアを含む構成図である。
統合プラットフォーム装置10は、クライアント80に加えて管理計算機90にも接続されている。管理計算機90は、計算機システムの管理者が、計算機システムを管理するために用いる計算機であり、例えば、管理者から各種指示を受け付けて統合プラットフォーム装置10に送信する。
統合プラットフォーム装置10では、メモリ21上のハイパバイザ60がCPU22により実行される。ハイパバイザ60は、統合プラットフォーム装置10の物理リソース(メモリ21、CPU22、NIC23等)を論理的に分割することにより得られた論理リソースを管理する。ハイパバイザ60は、論理リソースが割り当てられたLPAR50を生成する。各LPAR50でOSが実行されてよい。ハイパバイザ60は、メモリ21を論理的に分割することにより、LPAR1用のメモリ領域1、LPAR2用のメモリ領域2、及び、LPAR1及び2の共有メモリ領域212を用意する。共有メモリ領域212には、例えば、後述するクラスタ構成管理テーブル100(図3参照)、引継ぎ情報管理テーブル110(図4参照)、及び障害監視管理テーブル130(図5参照)が管理される。
CPU22を論理的に分割することにより、論理リソースとして、CPU1及びCPU2が得られる。CPU1は、LPAR1のCPU(LPAR1に割り当てられた論理リソース)であり、CPU2は、LPAR2のCPUである。
LPAR50は、ファイル共有プログラム51と、ファイルシステム52と、フェールオーバプログラム53と、カーネル/ドライバ54とを実行する。
ファイル共有プログラム51は、CIFS(Common Internet File System)、NFS(Network File System)等の通信プロトコルを使用して、複数のクライアント間でファイルを共有することのできるファイル共有サービスを提供する。
ファイルシステム52は、LU311上にファイルという管理単位を実現するために構築された論理構造を含む。本実施例では、ファイルシステム52は、論理構造を管理するファイルシステムプログラムを含む。ファイルシステム52は、論理構造として、スーパーブロック、inode管理テーブル、データブロックを含む。スーパーブロック、inode管理テーブル、及びデータブロックは、公知であるので、ここでは、簡単な説明に留める。スーパーブロックは、ファイルシステムの情報を一括保持する。例えば、スーパーブロックは、ファイルシステムの大きさ、ファイルシステムの空き容量等のファイルシステム全体の管理情報を保持する。inode管理テーブルは、個々のファイル/ディレクトリのメタ情報を管理する。inode管理テーブルは、ファイルについては、データブロックへのアドレスも管理する。なお、ファイルシステム52の構造体は、LU311に格納されており、その構造体の一部又は全部がLPAR用のメモリ領域に呼び出される。
フェールオーバプログラム53は、同一のクラスタの他のLPAR50の障害発生を監視し、障害を検知した場合には、障害元のLPAR50で稼働していたリソース(IPアドレス、ファイルシステム等)を引継いで、障害元のLPAR50で実行していたファイル共有サービスを再開させるフェールオーバを実行する。
カーネル/ドライバ54は、統合プラットフォーム装置10上で動作する複数のプログラム(プロセス)のスケジュールを制御したり、ハードウェアからの割込みをハンドリングしたりする等の全般的な制御及びハードウェア固有の制御を行うプログラムである。
RAID制御部30は、RAIDグループに基づくLU311に対して入出力処理を実行する。
図2に示すように、LAPR n(n=1又は2)が実行するプログラム、及び、LPAR nに割り当てた論理リソースには、LPARと同じ番号nが割り振られている。以下、説明が冗長になることを避けるために、LPAR nが実行するプログラム又はLPAR nに割り当てられた論理リソースを、参照符号に代えて番号nを使用して説明することがある。
図3は、クラスタ構成管理テーブルの一例の構成図である。
クラスタ構成管理テーブル100は、相手ノード名称100a、監視間隔100b、リソースグループ数100c、リソースグループ 100dのフィールドを有する。
相手ノード名称100aには、クラスタ構成となる相手のノード(LPAR)のノード名が格納される。監視間隔100bには、障害監視を行う時間間隔が格納される。リソースグループ数100cには、LPARにおけるファイル共有サービスを提供する上で必要なリソースをグループ化したリソースグループの数が格納される。リソースグループ 100dの数は、リソースグループ数100cに設定されたリソースグループの数以上である。リソースグループ 100dには、リソースグループに関する情報(リソースグループ情報)、例えば、リソースグループに対してクライアント80からアクセスするためのIPアドレスと、リソースグループに属するファイルシステムの数と、リソースグループに属する各ファイルシステムのファイルシステム名とが格納される。
図4は、引継ぎ情報管理テーブルの一例の構成図である。
引継ぎ情報管理テーブル110は、NFS設定情報110aと、CIFS設定情報110bと、ロック情報110cとのフィールドを有する。
NFS設定情報110a及びCIFS設定情報110bには、それぞれ、公開先IPアドレス、公開dir名、及びアクセス権が格納される。公開先IPアドレスは、ファイルシステムを公開している計算機(クライアント等)のIPアドレスである。公開dir名は、公開しているディレクトリの名称である。公開しているディレクトリとしては、ファイルシステム内のディレクトリ、ファイルシステムのルートディレクトリ、又はグローバルネームスペースのルートディレクトリであっても良い。アクセス権は、公開先に対してどのようなアクセスが許可されているかを示す。アクセス権としては、リードのみ許可、リード及びライト許可等がある。
ロック情報110cには、ファイル名及びIPアドレスが格納される。ファイル名は、ロック対象のファイルの名称である。IPアドレスは、ファイル名のファイルをロックしている計算機(ロックオーナ)のIPアドレスである。
本実施例の説明では、クラスタ構成管理テーブル100に格納される情報全体を、「クラスタ構成情報」と呼び、引継ぎ情報管理テーブル110に格納される情報全体を、「引継ぎ情報」と呼ぶことがある。クラスタ構成管理テーブル100及び引継ぎ情報管理テーブル110に設定されている情報が引継ぎ必要情報の一例である。
図5は、障害監視管理テーブルの一例の構成図である。
障害監視管理テーブル120は、カウンタ1 120aと、カウンタ2 120bと、障害フラグ120cとのフィールドを有する。カウンタ1 120aには、LPAR1によりカウントアップされるカウント値が格納される。カウンタ2 120bには、LPAR2によりカウントアップされるカウント値が格納される。カウント値は、カウントアップに代えてカウントダウン等の別の方法により更新されてもよい。カウント値が確認用情報の一例である。障害フラグ120cには、LPARに障害が発生したか否かを示すフラグ(障害フラグ)が格納される。障害フラグは、ハイパバイザ60がLPARの障害を検知した時にON(オン)に設定される。
以下、本実施例で行われる処理を説明する。
まず、初期処理を、図6及び図11を参照して説明する。
図6は、初期処理の模式図であり、図11は、初期処理のフローチャートである。
管理計算機90は、管理者からLPAR1についてのクラスタ構成情報及び引継ぎ情報の入力を受け付け、クラスタ構成要求の指示を受け付ける(図6(1))と、受け付けたクラスタ構成情報及び引継ぎ情報を統合プラットフォーム装置10のLPAR1に送信する(図6(2))。
LPAR1のフェールオーバプログラム1は、管理計算機90からクラスタ構成情報及び引継ぎ情報を受信し(図11(S11))、カーネル/ドライバ54に対して、共有メモリ領域の確保要求を行う(図11(S12)、図6(3))。カーネル/ドライバ54は、ハイパバイザ60に対して、共有メモリ領域の確保要求を行う(図6(4))。共有メモリ領域の確保要求を受け取ったハイパバイザ60は、メモリ21から共有メモリ領域212を確保する(図6(5))。
共有メモリ領域212が確保された後、フェールオーバプログラム1は、カーネル/ドライバ1を介して、共有メモリ領域212にクラスタ構成情報をクラスタ構成管理テーブル100として登録し(図11(S13)、図6(6))、共有メモリ領域212に、引継ぎ情報を引継ぎ情報管理テーブル110として登録する(図11(S14)、図6(6))。なお、クラスタ構成情報の一部、及び、引継ぎ情報の一部、のうちの少なくとも一方が、共有メモリ領域212に代えて又は加えて、少なくとも1つのLU311に格納されてもよい。
その後、フェールオーバプログラム1は、障害監視処理(図8、図15、図16、及び図17参照)を開始する(S15)。
次に、初期処理後の1つの処理である通常処理を、図7、図12、及び図13を参照して説明する。
図7は、通常処理の模式図であり、図12は、ファイルアクセス処理のフローチャートであり、図13は、デステージ処理のフローチャートである。
クライアント80は、ユーザからファイルアクセス要求の指示を受け付ける(図7(1))と、受け付けたファイルアクセス要求をLPAR1に送信する(図7(2))。
LPAR1のファイル共有プログラム1は、クライアント80からファイルアクセス要求を受信すると、ファイルアクセス要求がライト要求であるか、リード要求であるかを判定する(S21)。この結果、ファイルアクセス要求がライト要求である場合(図12(S21:Yes))には、ファイル共有プログラム1は、ファイルアクセス要求に従うアクセス対象ファイルのロックを取得し、共有メモリ領域212の引継ぎ情報管理テーブル110に、取得したロックの内容を反映する(図12(S22)、図7(3))。ファイル共有プログラム1は、ファイルシステム1に対して、ファイルのライト要求を行う(図12(S23)、図7(4))。
ファイルシステム1は、メモリ領域1(占有メモリ領域1)のファイルに対してライト要求に対応するライト処理を実行する(図12(S24)、図7(5))。なお、ファイルシステム52は、図13に示すように、メモリ領域1に十分な空きがあるか否かを判定し(図13(S41))、メモリ領域1に十分な空きがない場合(図13(S41:No))には、使用率の低いファイルをデステージする、すなわち、使用率の低いファイルをメモリ領域1からLU311へ書き込む(図13(S42)、図7(6))。
ファイルシステム1によるライト処理の実行後に、ファイル共有プログラム1は、要求元のクライアント80に応答を返し(図12(S25))、ロックを解除し、共有メモリ領域212の引継ぎ情報管理テーブル110から、解除したロックの内容を削除し(図12(S26))、ファイルアクセス処理を終了する。
一方、ファイルアクセス要求がリード要求である場合(図12(S21:No))には、ファイル共有プログラム1は、ファイルアクセス要求に従うアクセス対象のファイルのロックを取得し、共有メモリ領域212の引継ぎ情報管理テーブル110に、取得したロックの内容を反映する(図12(S27)、図7(3))。ファイル共有プログラム51は、ファイルシステム52に対して、ファイルのリード要求を行う(図12(S28)、図7(4))。
ファイルシステム1は、メモリ領域1(占有メモリ領域1)のファイルに対してリード要求に対応するリード処理を実行する(図12(S29)、図7(5))。
ファイルシステム1によるリード処理の実行後に、ファイル共有プログラム1は、要求元のクライアント80に取得したファイルを返し(図12(S30))、ロックを解除し、共有メモリ領域212の引継ぎ情報管理テーブル110から、解除したロックの内容を削除し(図12(S31))、ファイルアクセス処理を終了する。
次に、障害監視処理を、図8、図9、図15、図16、及び図17を参照して説明する。
図8は、障害監視処理の一部分の模式図であり、図9は、障害監視処理の残り部分の模式図であり、図15は、カウンタ更新処理のフローチャートであり、図16は、障害確認処理及びフェールオーバ処理のフローチャートであり、図17は、カウンタ監視処理のフローチャートである。
図8に示すように、フェールオーバプログラム1及び2は、障害監視管理テーブル120のそれぞれのLPARに対応するカウンタの値を所定の時間毎に更新する(図8(1)、図15(S51))。
一方、ハイパバイザ60は、障害監視管理テーブル120のそれぞれのLPARに対応するカウンタの値を確認し(図8(2)、図17(S81))、各カウンタが一定期間内に更新されたか否かを判定する(図17(S82))。この結果、更新されている場合(S82:Yes)には、ハイパバイザ60は、処理をS81に進め、更新されていない場合(S82:No)には、障害監視管理テーブル120の障害フラグ120cの値をONに設定する(図8(3)、図17(S83))。LPARに障害が発生していることを通知するためである。
次に、フェールオーバプログラム1(2)は、カーネル/ドライバ1(2)及びハイパバイザ60を介して、共有メモリ領域212の障害監視管理テーブル120の障害フラグ120cの値を監視する(図9(1)、図16(S61))。
フェールオーバプログラム1(2)は、障害が発生しているか否かを判定する(S62)。具体的には、フェールオーバプログラム1(2)は、共有メモリ領域212の障害監視管理テーブル120の障害フラグ120cの値がONである場合には、障害が発生していると判定する。この結果、障害が発生していない場合(図16(S62:No))には、フェールオーバプログラム1(2)は、処理をS61に進め、障害が発生している場合(S62:Yes)には、後述するフェールオーバ処理(S63~S67)を実行する。
ここで、障害が発生した場合を例に計算機システムの動作を説明する。
図14は、障害監視処理及びフェールオーバ処理のシーケンス図である。
LPAR1及びLPAR2においても障害が発生していない場合には、図15に示すカウンタ更新処理のS51により、フェールオーバプログラム1は、障害監視管理テーブル120のカウント値1(カウンタ1 120aのカウント値)を所定の時間毎に更新し(図14(1))、フェールオーバプログラム2は、障害監視管理テーブル120のカウント値2(LPAR2に対応するカウンタ2 120bのカウント値)を所定の時間毎に更新する(図14(2))。この結果、ハイパバイザ60によるカウンタ監視処理(図17)においては、障害監視管理テーブル120の障害フラグ120cの値は、ONに設定されない(図14(3))。
しかし、LPAR1において障害が発生すると、フェールオーバプログラム1は、カウンタ更新処理のS51により、カウント値1を更新することができなくなる(図14(4))。この結果、以降に行われるカウンタ監視処理(図17)において、カウント値1が一定期間更新されていないことが検出され、障害監視管理テーブル120の障害フラグ120cの値が、ONに設定されることとなる(図14(5))。
この後、LPAR2のフェールオーバプログラム2が、図16に示す障害確認処理及びフェールオーバ処理を実行すると、障害監視管理テーブル120の障害フラグ120cの値がONに設定されているので、S62で障害が発生していると判定され、後続のフェールオーバ処理(S63~S67)が実行される(図14(6))。
次に、LPARに障害が発生している場合におけるフェールオーバ処理を図10及び図16を参照して説明する。障害が発生した一方のLPARをLPAR1とし、他方のLPARをLPAR2とする。
LPAR1において障害が発生したことを検出したフェールオーバプログラム2は、カーネル/ドライバ2及びハイパバイザ60を介して、共有メモリ領域212のクラスタ構成管理テーブル100からリソースグループ情報(具体的には、クラスタ構成管理テーブル100のリソースグループ 100dに設定されている情報)を取得する(図10(1)、図16(S63))。次に、フェールオーバプログラム2は、リソースグループ情報から特定されるファイルシステムをチェックし、そのファイルシステムをLPAR2にマウントする(図10(2)、図16(S64))。これにより、LPAR2は、LPAR1が使用していたファイルシステムを使用できるようになる。
次に、フェールオーバプログラム53は、リソースグループ情報に含まれているIPアドレスをLPAR2のIPアドレスに設定する(図10(3)、図16(S65))。これにより、LPAR2は、LPAR1がクライアント80から受信していたアクセス要求を受信できるようになる。
次に、フェールオーバプログラム2は、カーネル/ドライバ2及びハイパバイザ60を介して、共有メモリ領域212の引継ぎ情報管理テーブル110から引継ぎ情報(具体的には、引継ぎ情報管理テーブル110のNFS設定情報110a、CIFS設定情報110b、ロック情報110cに設定された情報)を取得し、取得した情報に基づいて、ファイル共有プログラム2を設定し(図10(4)、図16(S66))、ファイル共有プログラム2による動作を再開してクライアント80からのアクセス要求を受け付け可能とする(図10(5))。
このように、NFS設定情報110a、CIFS設定情報110b、ロック情報110cに設定された情報に基づいてファイル共有プログラム2を設定するので、ファイル共有プログラム2を、LPAR1におけるファイル共有プログラム1の使用状態と同じ状態としてファイル共有サービスを提供できる。例えば、LPAR1においてファイルシステムを公開していたクライアント80に対して、同様のアクセス権のファイル共有サービスを提供することができる。また、LPAR1においてファイルシステムを使用していた場合におけるロックの状態を維持することができる。したがって、或るクライアント80からのファイルアクセス要求によって或るファイルに対してロックがかけられた状態において、LPAR1に障害が発生した場合であっても、LPAR2において、そのロックの状態を引継ぐことができるので、ロックされていたファイルが他のクライアント80により占有されることを防止でき、クライアント80に対してファイルアクセスを継続させることができる。
次に、フェールオーバプログラム2は、障害の発生したLPAR1をリセットするリセット処理(図16(S71~S73))を行う(図16(S64))。なお、このリセット処理を実行するにあたっては、障害の発生したLPAR1のメモリ領域1のデータをクリア(消去)しないようにしている。
リセット処理では、フェールオーバプログラム2は、障害の発生したLPAR1のメモリ領域1中の未使用領域にOSをロードし、OSを起動する(図16(S71))。
次に、フェールオーバプログラム2は、カーネル/ドライバ2及びハイパバイザ60を介して、障害の発生したLPAR1のメモリ領域1中の実際に使用されている領域のデータを読込み(図16(S72))、読込んだデータをファイルとして出力する(図16(S73))。これにより、障害の発生したLPAR1が使用していたメモリ領域1の情報を適切にファイルにすることができる。
次に、計算機システムにおける一部の処理をより詳細に説明する。
図18は、共有メモリ領域へのアクセスを説明するシーケンス図である。図18に示すシーケンスは、図11に示すS12乃至S14の処理、図16のS63及びS66の処理に関連する。
まず、共有メモリ領域を確保する処理(S12)に関わる処理について説明する。
LPAR1のフェールオーバプログラム1は、ハイパバイザ60に対してサイズを指定して共有メモリ領域確保要求を送信する(S91)。ここで指定するサイズとしては、例えば、クラスタ構成管理テーブル100、引継ぎ情報管理テーブル110、及び障害監視管理テーブル120の初期サイズと、運用開始後に増加すると考えられる引継ぎ情報管理テーブル110の増加分とを考慮したサイズである。ハイパバイザ60は、共有メモリ領域確保要求を受信すると、要求に従ったサイズの共有メモリ領域212の領域を確保する(S92)。次に、ハイパバイザ60は、LPAR1に対して、共有メモリ領域212を一意に識別するためのハンドルを送信する(S93)。ここで、ハンドルには、例えば、共有メモリ領域確保要求を行ったLPAR1のIDと、メモリ領域21における共有メモリ領域212の先頭アドレスとが含まれる。
次に、確保した共有メモリ領域212にデータを格納する処理(S13)に関わる処理について説明する。
LPAR1は、共有メモリ領域212にデータを格納する際には、受信したハンドル、書き込むデータのサイズであるオフセット、及びデータを含むライト要求をハイパバイザ60に送信する(S94)。ハイパバイザ60は、ライト要求に従って共有メモリ領域212にデータを格納し(S95)、ライト要求の処理結果をLPAR1に送信する(S96)。
LPAR1は、共有メモリ領域212にアクセスするためのハンドルをLPAR2に送信する(S97)。LPAR2のフェールオーバプログラム2は、共有メモリ領域にアクセスするためのハンドルをLPAR2のメモリ領域2に格納する(S98)。このハンドルにより、LPAR2は、確保された共有メモリ領域212に対して適切にアクセスすることができる。
次に、共有メモリ領域212に格納されたデータをLPAR2で読み出す処理(S63、S66)に関わる処理について説明する。
共有メモリ領域212からデータを読み出す必要がある場合(S63、S66)には、LPAR2のフェールオーバプログラム2は、LPAR2のメモリ領域2に格納しているハンドルと、読み出すデータのサイズを示すオフセットとを含むリード要求をハイパバイザ60に送信する(S99)。ハイパバイザ60は、リード要求に従って共有メモリ領域212からデータを読み出し(S100)、読み出したデータをLPAR2に送信する(S101)。
このように、共有メモリ領域212を必要な時点で確保し、共有メモリ領域212を特定することのできるハンドルをLPAR2に渡すようにしているので、共有メモリ領域212を予め用意しておく必要がない。
図19は、メモリダンプ処理のシーケンス図である。図19に示すシーケンスは、主に、図16のS72及びS73に関わる各構成の処理に対応する。
S72においては、LPAR2のフェールオーバプログラム2は、ハイパバイザ60に対してLPAR1のメモリ領域1(占有メモリ領域1)の情報の取得要求を送信する(S111)。ハイパバイザ60は、占有メモリ領域1の情報の取得要求に従って占有メモリ領域1にアクセスし(S112)、LPAR1の占有メモリ領域情報を取得する(S113)。ここで、ハイパバイザ60は、LPAR1のメモリ領域1の状態を把握しており、且つLPAR1に障害が発生し、占有メモリ領域1を使用することはないので、排他制御を行うことなく容易にLPAR1の占有メモリ領域情報を取得することができる。次に、ハイパバイザ60は、取得した占有メモリ領域情報を、LPAR2に返却する(S114)。ハイパバイザ60から占有メモリ領域情報の返却を受けたLPAR2のフェールオーバプログラム2は、占有メモリ領域情報をPDEVへ書き出す(S73)。これにより、LPAR1に障害が発生していても、適切にLPAR1の占有メモリ領域1の情報を回収することができ、障害の解析等を適切に行うことができる。
以上、一実施例を説明したが、本発明は、この実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、LPARに障害が発生したことを、ハイパバイザ60が直接的に他のLPARのフェールオーバプログラム53に通知するようにしても良い。
10:統合プラットフォーム装置 20:サーバ部 30:RAID制御部 80:クライアント 90:管理計算機
Claims (12)
- 上位装置に接続された通信インタフェースと、メモリと、それらに接続されたプロセッサとを含んだ物理リソースと、
前記物理リソースを論理的に分割することにより得られた第1及び第2論理リソースがそれぞれ割り当てられた第1及び第2論理区画を管理する仮想化機構と
を有し、
前記第1及び第2論理区画は、それぞれ、前記記憶デバイスに対するデータ入出力処理を実行可能であり、
前記仮想化機構が、前記メモリに基づく領域であり前記第1及び第2論理区画がアクセス可能な共有メモリ領域を提供し、
前記第1論理区画は、前記共有メモリ領域に対して、前記第1論理区画が担当しているデータ入出力処理を前記第2論理区画に引継ぐために必要な引継ぎ必要情報を格納し、
前記第2論理区画は、前記第1論理区画における障害の発生を検出した場合に、前記共有メモリ領域から前記引継ぎ必要情報を取得し、前記引継ぎ必要情報に基づいて、前記第1論理区画が担当していた前記データ入出力処理を引継いで実行する、
ストレージ装置。 - 前記仮想化機構は、前記第1論理区画に障害が発生したか否かを監視し、障害が発生した場合に、前記第1論理区画に障害が発生したことを前記第2論理区画が認識できるようにする、
請求項1記載のストレージ装置。 - 前記第1論理区画は、正常動作時には、所定の時間間隔で正常動作していることを示す確認用情報を前記共有メモリ領域に書込み、
前記仮想化機構は、前記共有メモリ領域の前記確認用情報を確認することにより、前記第1論理区画に障害が発生したか否かを判定する、
請求項2記載のストレージ装置。 - 前記第1論理区画は、前記仮想化機構から前記共有メモリ領域の割当てを受け、割当てられた前記共有メモリ領域に対して、前記引継ぎ必要情報を書込む、
請求項1記載のストレージ装置。 - 前記第1論理区画は、前記第2論理区画に対して、割当てられた前記前記共有メモリ領域を特定可能なハンドルを送信し、
前記第2論理区画は、前記第1論理区画に障害が発生したことを認識した場合に、前記ハンドルを用いて、前記共有メモリ領域にアクセスして前記引継ぎ必要情報を取得する、
請求項4記載のストレージ装置。 - 前記第1論理区画及び前記第2論理区画は、前記仮想化機構を介して前記共有メモリ領域にアクセスする、
請求項1記載のストレージ装置。 - 前記第1論理区画は、ファイルシステムを有し、前記ファイルシステムを用いて、前記上位装置から要求されたファイルのデータ入出力処理を実行し、
前記引継ぎ必要情報は、前記第1論理区画が有する前記ファイルシステムを特定する情報を含む、
請求項1記載のストレージ装置。 - 前記引継ぎ必要情報は、前記上位装置が前記ファイルシステムにアクセスするためのアドレス情報を更に含む、
請求項7記載のストレージ装置。 - 前記引継ぎ必要情報は、前記ファイルシステムにアクセス可能な上位装置を示す識別情報を更に含む、
請求項8記載のストレージ装置。 - 前記引継ぎ必要情報は、前記ファイルシステムにアクセス可能な上位装置に関するアクセス権限を示す情報を更に含む、
請求項9記載のストレージ装置。 - 前記引継ぎ必要情報は、前記ファイルシステムのファイルのロックに関する情報を含み、
前記第1論理区画は、前記上位装置からファイルに対するアクセス要求を受け付けた場合に、前記ファイルのロックに関する情報を、前記引継ぎ必要情報に反映する、
請求項1記載のストレージ装置。 - 上位装置に接続された通信インタフェースと、メモリと、それらに接続されたプロセッサとを含んだ物理リソースを論理的に分割することにより得られた第1及び第2論理リソースがそれぞれ割り当てられた第1及び第2論理区画に対し、前記メモリに基づく領域であり前記第1及び第2論理区画がアクセス可能な共有メモリ領域を提供し、
前記第1論理区画は、前記共有メモリ領域に対して、前記第1論理区画が担当しているデータ入出力処理を前記第2論理区画に引継ぐために必要な引継ぎ必要情報を格納し、
前記第2論理区画は、前記第1論理区画における障害の発生を検出した場合に、前記共有メモリ領域から前記引継ぎ必要情報を取得し、前記引継ぎ必要情報に基づいて、前記第1論理区画が担当していた前記データ入出力処理を引継いで実行する、
フェールオーバ方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2013/077783 WO2015052836A1 (ja) | 2013-10-11 | 2013-10-11 | ストレージ装置及びフェールオーバ方法 |
US14/371,147 US9262289B2 (en) | 2013-10-11 | 2013-10-11 | Storage apparatus and failover method |
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)
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015114816A1 (ja) * | 2014-01-31 | 2015-08-06 | 株式会社日立製作所 | 管理計算機および管理プログラム |
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)
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)
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 | 株式会社日立製作所 | 仮想計算機システム |
US8607020B2 (en) * | 2008-06-06 | 2013-12-10 | International Business Machines Corporation | Shared memory partition data processing system with hypervisor managed paging |
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 | 株式会社日立製作所 | 仮想計算機システム |
-
2013
- 2013-10-11 WO PCT/JP2013/077783 patent/WO2015052836A1/ja active Application Filing
- 2013-10-11 US US14/371,147 patent/US9262289B2/en active Active
Patent Citations (5)
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)
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 |
---|---|
US20150301913A1 (en) | 2015-10-22 |
US9262289B2 (en) | 2016-02-16 |
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 | |
EP3799396B1 (en) | Provisioning and allocation of external memory | |
US9733958B2 (en) | Mechanism for performing rolling updates with data unavailability check in a networked virtualization environment for storage management | |
US20200371700A1 (en) | Coordinated allocation of external memory | |
US20160378355A1 (en) | Method and system for implementing performance tier de-duplication in a virtualization environment | |
WO2015052836A1 (ja) | ストレージ装置及びフェールオーバ方法 | |
US20240053886A1 (en) | File operations in a distributed storage system | |
CN107710160B (zh) | 计算机和存储区域管理方法 | |
US11822445B2 (en) | Methods and systems for rapid failure recovery for a distributed storage system | |
WO2011111249A1 (ja) | 仮想計算機システム及び仮想計算機の制御方法 | |
US12013758B2 (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 |