WO2018229944A1 - ストレージシステム及びストレージシステムの制御方法 - Google Patents

ストレージシステム及びストレージシステムの制御方法 Download PDF

Info

Publication number
WO2018229944A1
WO2018229944A1 PCT/JP2017/022160 JP2017022160W WO2018229944A1 WO 2018229944 A1 WO2018229944 A1 WO 2018229944A1 JP 2017022160 W JP2017022160 W JP 2017022160W WO 2018229944 A1 WO2018229944 A1 WO 2018229944A1
Authority
WO
WIPO (PCT)
Prior art keywords
stripe
node
parity
block
data
Prior art date
Application number
PCT/JP2017/022160
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 US16/327,349 priority Critical patent/US10713117B2/en
Priority to PCT/JP2017/022160 priority patent/WO2018229944A1/ja
Priority to JP2019524668A priority patent/JP6807457B2/ja
Publication of WO2018229944A1 publication Critical patent/WO2018229944A1/ja

Links

Images

Classifications

    • 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/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076—Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • 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/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0607—Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0688—Non-volatile semiconductor memory arrays
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems

Definitions

  • the present invention relates to a storage system.
  • a Server SAN type storage system that creates a storage pool by connecting a large number of general-purpose servers via a network is expected to become popular in the future.
  • the ServerSAN storage system is considered to be an effective solution in a system that aims at high-performance analysis by installing a high-speed SSD in a server node for large-scale big data analysis or the like.
  • a RAID (Redundant Array of Independent (or Independent) Disks) group is configured by a plurality of storage devices (Nodes), and a logical volume generated based on the RAID group is provided to a higher-level device (for example, a host computer).
  • Storage systems are known.
  • the bit cost of the RAID group is determined by the ratio of the number of data blocks constituting the RAID and the number of protection blocks (mirror blocks or parity blocks) for redundancy.
  • the capacity efficiency of a RAID group composed of nD + mP is n / (n + m) where the number of data blocks (D) is n and the number of parity blocks (P) is m.
  • Patent Document 1 discloses a method for constructing a highly reliable system while reducing read latency by appropriately distributing and arranging Write data to each Node in a ServerSAN storage system. Has been.
  • Patent Document 2 discloses a method for improving the capacity efficiency of a system by expanding an existing RAID group (eg, 3D + 1P ⁇ 4D + 1P).
  • Patent Document 1 discloses a Node expansion method that maintains a RAID group configuration (also referred to as a stripe configuration).
  • a RAID group configuration also referred to as a stripe configuration.
  • 2D + 1P capacity efficiency 67%) is the most because of the RAID5 restriction that all the data constituting the stripe must be stored in different nodes. A stripe configuration with high capacity efficiency is obtained.
  • Patent Document 2 discloses a method for improving the capacity efficiency of the system by expanding the stripe configuration.
  • the method described in Patent Document 2 requires rearrangement of all data stored in the system.
  • a Server SAN type storage system that is the main object of the present invention, that is, a scale-out type system
  • the band between nodes is generally narrower than the band inside the storage, and the extension processing of the stripe configuration
  • the extension processing of the stripe configuration There was a problem that it took a huge amount of time to complete.
  • an object of the present invention is to reduce the amount of data movement between Nodes and increase the speed of node expansion processing when expanding the stripe configuration.
  • the present invention is a storage system that includes a plurality of nodes including a processor, a memory, and a storage area, and a plurality of the nodes include data blocks and parity blocks to form a stripe.
  • an intermediate parity is generated from a data block included in the first node and a parity block included in the first node and included in the processing target stripe, and the intermediate parity is , Transferred to the second node, stored as parity in the block of the second node, the data block used as the basis for generating the intermediate parity, the block storing the parity, the first and second A stripe is composed of data blocks in the stripe to be processed other than the current node.
  • the amount of data movement between nodes is reduced when the stripe configuration is expanded.
  • the Scale-out configuration it is possible to reduce the amount of data rearrangement movement and improve the capacity efficiency at high speed.
  • FIG. 1 is a block diagram illustrating an example of a hardware configuration of a computer system according to a first embodiment of this invention. It is Example 1 of this invention and is a block diagram which shows an example of the control information storage area of a cache memory.
  • 1 is a block diagram illustrating an example of a control program storage area of a cache memory according to a first embodiment of this invention.
  • FIG. 1 is a block diagram illustrating an example of a data configuration of a storage drive according to a first embodiment of this invention.
  • FIG. FIG. 2 is a diagram illustrating an example of a RAID group configuration according to the first embodiment of this invention. It is a figure which shows Example 1 of this invention and shows an example of the data arrangement of a RAID group structure.
  • FIG. 1 is a diagram illustrating an example of a logical configuration of a storage area of a computer system according to a first embodiment of this invention.
  • FIG. It is Example 1 which shows Example 1 of this invention and shows an example of a stripe management table. It is a figure which shows Example 1 of this invention and shows an example of a Node management table.
  • FIG. 10 is a diagram illustrating an example of a drive management table according to the first embodiment of this invention. It is a figure which shows Example 1 of this invention and shows an example of a Pool Volume management table. It is a figure which shows Example 1 of this invention and shows an example of a Pool management table. It is Example 1 which shows Example 1 of this invention and shows an example of a VVOL management table.
  • Example 1 of this invention shows an example of a parity Node table. It is a figure which shows Example 1 of this invention and shows an example of an unallocated block management table. It is a figure which shows Example 1 of this invention and shows the outline
  • Example 1 of this invention is a flowchart which shows an example of the update process (period head) of a stripe structure. It is Example 1 of this invention, and is a flowchart which shows an example of the update process (period middle) of a stripe structure. It is Example 1 of this invention, and is a flowchart which shows an example of the update process (before a period end) of a stripe structure. It is Example 1 of this invention, and is a flowchart which shows an example of the update process (period end) of a stripe structure. 5 is a flowchart illustrating an example of stripe configuration update processing (fraction) according to the first embodiment of this invention.
  • aaa table various types of information may be described using the expression “aaa table”, but the various types of information may be expressed using a data structure other than a table.
  • the “aaa table” can also be referred to as “aaa information” to indicate that it does not depend on the data structure.
  • the process may be described using “program” as a subject.
  • the program is executed by a processor (for example, a CPU (Central Processing Unit)), so that a predetermined process is appropriately performed. Since the processing is performed using a storage resource (for example, a memory) and / or a communication interface device (for example, a port), the subject of the processing may be a program.
  • a processor for example, a CPU (Central Processing Unit)
  • a storage resource for example, a memory
  • a communication interface device for example, a port
  • the processing described with the program as the subject may be processing performed by a processor or a computer having the processor (for example, a management computer, a host computer, a controller, etc.).
  • the controller storage controller
  • the program may be installed in each controller from a program source.
  • the program source may be, for example, a program distribution server or a computer-readable storage medium.
  • an ID is used as element identification information, but other types of identification information may be used instead of or in addition thereto.
  • a reference number or a common number in the reference number is used, and when a description is made by distinguishing the same type of element, the reference number of the element is used.
  • an ID assigned to the element may be used instead of the reference code.
  • an I / O (Input / Output) request is a write request or a read request, and may be called an access request.
  • FIG. 1 is a block diagram illustrating an example of a hardware configuration of the computer system according to the first embodiment.
  • the computer system 1 includes one or more host computers (hereinafter referred to as hosts) 10, a management server 20, and a plurality of Nodes 100-1 to 100n.
  • hosts host computers
  • the host 10, the management server 20, and the Nodes 100-1 to 100n are connected via the network 150.
  • the symbol “100” in which “ ⁇ ” and the subsequent symbols are omitted is used. The same applies to the reference numerals of other components.
  • the network 150 may be a local area network (LAN: Local Area Network) or a wide area network (WAN: Wide Area Network). Further, the host 10 and the Node 100 may be one computer. Further, each of the host 10 and the Nodes 100-1 to 100n may be a virtual machine.
  • LAN Local Area Network
  • WAN Wide Area Network
  • the host 10 is, for example, a computer that executes an application, reads data used by the application from the Node 100, and writes data generated by the application to the Node 100.
  • Management server 20 is a computer used by an administrator.
  • the management server 20 may include an input device (not shown) for inputting information and an output device (not shown) for displaying information.
  • the management server 20 receives the setting of the data rearrangement process when the Node 100 is added or reduced by the administrator's operation on the input device, and causes the Node 100 to execute the received data rearrangement process.
  • the Node 100 includes one or more ports 110, one or more management I / Fs 120, one or more CPUs 130, one or more cache memories (CM: Cache Memory in the figure), one or more storage drives 160, an internal Network 150.
  • CM Cache Memory in the figure
  • the port 110, the management I / F 120, the CPU 130, the CM 140, and the storage drive 160 are connected via an internal network 150.
  • the port 110 is an example of an interface with the host 10.
  • the port 110 connects the Node 100 to various devices such as another Node 100 via the network 150 or the like.
  • the management I / F 112 is an interface for connecting the Node 100 to the management server 20.
  • the port 110 and the management I / F 120 may be the same.
  • the CPU 130 is a control unit, and executes various processes by executing a program stored in the control program storage area 142 of the cache memory 140.
  • the CPU 130 transmits various commands (for example, a READ command and a WRITE command in SCSI) to the storage drive 160.
  • the cache memory 140 temporarily stores data to be written from the host 10 to the storage drive 160 (write data) and data read from the storage drive 160 (read data).
  • a control program storage area 142 for storing various programs and a control information storage area 141 for storing various information are set. These pieces of information may be stored in a dedicated memory other than the cache memory 140, and a logical shared memory is configured using a storage drive 160 and a plurality of storage areas in the cache memory 140. However, cache management may be performed for various types of information.
  • the storage drive 160 includes one or more storage media.
  • the storage medium is, for example, a magnetic disk, flash memory, or other nonvolatile semiconductor memory (PRAM, ReRAM, etc.).
  • the Node 100 manages a capacity pool (hereinafter simply referred to as a pool) composed of storage areas of a plurality of storage drives 160.
  • the Node 100 configures a RAID group using a storage area in the pool. In other words, the Node 100 configures a plurality of logical RAID groups using the storage drives 160 in each Node.
  • the logical RAID group is composed of a plurality of sub storage area columns.
  • Each sub storage area column is composed of a plurality of sub storage areas.
  • the plurality of sub storage areas straddle the plurality of storage drives 160 constituting the RAID group, and correspond to the plurality of storage drives 160, respectively.
  • one sub storage area is referred to as a “stripe block”, and a sub storage area column is referred to as a “stripe”.
  • a storage area of the RAID group is configured by a plurality of stripe columns.
  • RAID levels There are several levels of RAID (hereinafter referred to as “RAID levels”). For example, in RAID5, write target data designated by a host computer corresponding to RAID5 is divided into data of a predetermined size (hereinafter referred to as “data unit” for convenience). Each data unit is divided into a plurality of data elements. A plurality of data elements are respectively written in a plurality of stripe blocks in the same stripe.
  • redundant information called “parity” is used for each data unit in order to rebuild data elements that cannot be read from the corresponding storage drive 160 due to a failure in the storage drive 160 or Node 100. (Hereinafter “redundant code”) is generated.
  • Redundant code is also written in stripe blocks within the same stripe as multiple data elements.
  • a stripe block in which user data is stored is called a “data block”
  • a block in which parity data is stored is called a “parity block”.
  • the number of storage drives 160 that is, Node 100 constituting the RAID group
  • three data elements constituting a data unit in three data blocks corresponding to the three storage drives 160 among them.
  • the redundant code is written in the parity block corresponding to the remaining one storage drive 160.
  • data elements and redundant codes are not distinguished from each other, they may be referred to as stripe blocks.
  • RAID 6 two types of redundant codes (P parity and Q parity) are generated for each data unit, and each redundant code is written in different parity blocks in the same stripe. Thereby, when two data elements out of a plurality of data elements constituting a data unit cannot be read, these two data elements can be restored from two types of redundant codes.
  • RAID levels other than those described above (for example, RAID 1 to 4).
  • a data redundancy technique a triple mirror (Triplication), a triple parity technique using three parities, and the like are also known.
  • the redundant code generation technique there are various techniques such as a Reed-Solomon code using Galois operation and EVEN-ODD.
  • RAID 5 will be mainly described, but the redundancy technique can be replaced with the method described above.
  • the Node 100 restores the data elements stored in the failed storage drive 160 when any one of the storage drives 160 or any Node 100 of the Nodes 100 fails.
  • a RAID group may be configured by the storage drives 160 in the nodes 100 and a RAID group may be configured between the nodes 100.
  • the CPU 130 stores the stripe block (for example, other data block and parity block) necessary for restoring the data element stored in the failed storage drive 160 via the port 110. Obtained from the storage drives 160 in other nodes.
  • the CPU 130 stores the acquired stripe block in the cache memory 140. Thereafter, the stripe block or the parity block is restored based on the stripe block of the cache memory 140, and the stripe block is stored in a predetermined storage drive 160.
  • the CPU 130 For example, for a stripe block of a RAID group configured with RAID 5, the CPU 130 generates a P parity by calculating an exclusive OR (XOR) of a plurality of data blocks constituting the stripe. For the data blocks of the RAID group configured with RAID 6, the CPU 130 further multiplies a plurality of data blocks constituting the stripe by a predetermined coefficient, and then calculates the exclusive OR of each data block. , Q parity is generated.
  • XOR exclusive OR
  • the process of the CPU 130 may be described as the process of the Node 100.
  • FIG. 2 is a block diagram showing the control information storage area 141 in the cache memory 140.
  • the control information storage area 141 includes a stripe management table 1001, a Node management table 1002, a drive management table 1003, a Pool Volume management table 1004, a Pool management table 1005, a VVOL management table 1006, a parity Node table 1007, An updating stripe management table 1009, an unallocated block management table 1008, and a copy pointer 1010 are stored. Each information will be described later.
  • FIG. 3 is a block diagram showing the control program storage area 142 in the cache memory 140.
  • the control program storage area 142 stores a node expansion processing program 1101, a stripe update processing program 1102, a rebuild processing program 1103, and an I / O processing program 1104.
  • the processing of each program other than the I / O processing program 1104 will be described later.
  • the I / O processing program 1104 is a program that receives an access request and executes reading and writing to the storage drive 160, and a known or publicly known technique may be applied.
  • the CPU 130 operates as a functional unit that provides a predetermined function by executing each program.
  • the CPU 130 functions as a node expansion unit by performing processing according to the node expansion processing program 1101. The same applies to other programs.
  • the CPU 130 also operates as a function unit that provides the functions of a plurality of processes executed by each program.
  • a computer and a computer system are an apparatus and a system including these functional units.
  • Information such as programs and tables for realizing each function of the node 100 is stored in storage devices such as the storage drive 160, nonvolatile semiconductor memory, hard disk drive, SSD (Solid State Drive), or IC cards, SD cards, DVDs, etc. It can be stored on a computer readable non-transitory data storage medium.
  • storage devices such as the storage drive 160, nonvolatile semiconductor memory, hard disk drive, SSD (Solid State Drive), or IC cards, SD cards, DVDs, etc. It can be stored on a computer readable non-transitory data storage medium.
  • FIG. 4 is a block diagram showing an example of the data configuration of the storage drive 160. As shown in FIG.
  • the storage drive 160 exchanges data with a device such as the Node 100 in units of the sub-block 200 that is the minimum unit of SCSI command processing (for example, 512 bytes).
  • the slot 201 is a management unit for caching data on the cache memory 140, and is, for example, 256 KB.
  • the slot 201 is composed of a set of a plurality of continuous sub blocks 200.
  • the stripe block 202 stores a plurality of (for example, two) slots 201.
  • FIG. 5A and FIG. 5B are schematic diagrams of a RAID group configuration according to the first embodiment.
  • FIG. 5A is a diagram showing details of the storage drive 160 and the stripe configuration in each of the Nodes 100-1 to 100-4.
  • Each Node 100 includes a plurality of storage drives 160, and the storage drives 160 are divided into stripe blocks 202 of a certain size.
  • the management server 20 selects a predetermined stripe block 202 in each of the nodes 100-1 to 100-4, and configures a logical RAID group (stripe 203) between the nodes 100-1 to 100-4. .
  • a logical RAID group stripe 203 between the nodes 100-1 to 100-4.
  • FIG. 5A the illustration of Node 100-3 is omitted.
  • the stripe 203-0 is composed of stripe blocks 202 of “A0”, “B0”, “C0”, and “P0”. “A0”, “B0”, “C0”, and “P0” are each composed of the leading stripe block 202 of the drive # 0 of each of the Nodes 100-1 to 100-4.
  • FIG. 5B shows an example in which stripes 203-0 to 203-9 are configured by the nodes 100-1 to 100-4.
  • the stripe block 202 in which user data is stored such as “A0”, “B0”, and “C0” in the figure, is referred to as a data block, and parity data is stored as “P0” in the figure.
  • the stripe block 202 is called a parity block.
  • the number of stripe blocks 202 constituting the stripe 203 is not necessarily the same as the number of Nodes 100.
  • the number of Nodes 100 is 10
  • a 3D + 1P stripe is formed in the computer system 1 in which the number of Nodes 100 is 10.
  • Four Nodes 100 may be selected from the ten Nodes 100, and the stripes 203 may be configured with predetermined stripe blocks 202 within each Node 100.
  • FIG. 6 is a diagram illustrating an example of a logical configuration of the computer system according to the first embodiment.
  • the computer system 1 configures one or more capacity pools 210 (hereinafter also simply referred to as pools) by bundling the areas of the storage drives 160 in the plurality of Nodes 100.
  • the pool 210 is composed of data blocks obtained by removing the area where the parity block is stored from the entire area of the storage drive 160.
  • the storage drive 160 in each Node 100 may be composed of a plurality of types of storage devices having different performance and characteristics, such as a flash memory drive, a SAS drive, and a SATA drive.
  • a flash memory drive such as a SSD
  • SAS drive such as a SAS
  • SATA drive such as a SATA drive
  • storage drives 160 with different performance and characteristics are mixed in the pool 210, the storage drive 160 with low performance becomes a bottleneck.
  • the pool 210 is composed of the storage drives 160 having a single performance and characteristics. For example, if there are storage drives 160 with different performance and characteristics in each Node 100, a plurality of pools 210 may be configured according to the performance and characteristics. Alternatively, the pool 210 may be divided by logical partitions (or tiers), and a page 213 described later may be configured by data blocks existing in a single tier.
  • Each Node 100 divides an internal physical storage area into a predetermined size, and generates a Pool Volume 211 (also referred to as PoolVol).
  • PoolVol a Pool Volume 211
  • the Pool Volume 211 is preferably composed of the storage drive 160 having a single performance and characteristics.
  • Each Node 100 configures the pool 210 by allocating the Pool Volume 211 to the appropriate pool 210.
  • the pool 210 can be considered to be composed of a plurality of Pool Volumes 211.
  • the Pool Volume 211 in the same Node 100 does not necessarily need to be assigned to the same pool 210, and may be assigned to a plurality of pools 210.
  • four Pool Volumes 211 of Node # 3 are assigned to pool # 0 and pool # 1, respectively.
  • VVOL Virtual Volume
  • the VVOL 212 is a virtual storage device and can be referenced from the host 10.
  • the management server 20 In response to an instruction from the administrator of the computer system 1, the management server 20 generates a VVOL 212 of a predetermined size via the management I / F 120 of the Node 100.
  • the size to be generated does not depend on the total usable capacity of the actual storage drive 160.
  • each Node 100 transfers the storage area (PoolVol page 214) in the pool 210 to the VVOL 212. Assign dynamically.
  • the storage area of the VVOL 212 can be managed by the VVOL page 213.
  • the VVOL page 213 is configured with stripe blocks 202 belonging to different Pool Volumes 211, I / O for the same VVOL page 213 is distributed to a plurality of Nodes 100, and an increase in latency due to transfer between Nodes 100 becomes a problem. .
  • the VVOL page 213 is preferably composed of the stripe block 202 in the same Pool Volume 211 as in the first embodiment.
  • the PoolVol page 214 is composed of one or more data blocks in the capacity pool 210.
  • the number of data blocks configuring the PoolVol page 214 is uniquely determined in the computer system, but does not depend on the configuration of the RAID group. Therefore, even when the configuration of the RAID group is changed, the allocation between the PoolVol page 214 and the data block is performed. There is no need to change.
  • the Node 100 When there are a plurality of Tiers in the pool 210, the Node 100 records the access frequency for each VVOL page 213, and for the VVOL page 213 with a high access frequency, for example, a high-performance storage drive 160 such as a flash memory drive.
  • a PoolVol page 214 configured in the above may be allocated.
  • the Node 100 may continuously monitor the load of the VVOL page 213 and periodically change the allocation of the VVOL page 213.
  • FIG. 7 is a diagram showing an example of the stripe management table 1001.
  • the stripe management table 1001 is information common to the computer system 1 and is information indicating a combination of stripe blocks in each Node 100 constituting the stripe 203. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the stripe management table 1001 includes a stripe # 2000 that stores the identifier of the stripe 203, a node # 2001 that holds the storage position of the stripe 203 for each identifier of each node 100 that constitutes the computer system 1, and a parity block included in the stripe 203
  • One entry includes a parity node # 2002 for storing the identifier of the node 100 at the storage location of NEXT 2003 and a NEXT 2003 field for storing a flag to be processed next time.
  • the Node 100 is configured with five “# 0” to “# 4”.
  • Stripe # 2000 is an identifier of the stripe 203
  • each Node # 2001 indicates a stripe block position (LBA #: Logical Block Address) in the Node corresponding to each Strip # 2000
  • Parity Node # 2002 stores a parity block. Node 100 that is being used is shown.
  • This table allows the Node 100 to refer to the Node # 2001 that constitutes each stripe 203, the stripe block position in the Node 100, and the Node 100 in which the parity block is stored.
  • FIG. 7 shows an example of the stripe management table when the number of parity blocks per stripe is 1, that is, RAID 5, but when the number of parity blocks per stripe is 2, ie, RAID 6, Q Parity is set to Parity Node # 2002. A block field is added.
  • the stripe 203 does not straddle all the Nodes 100 in the computer system 1.
  • the stripe block position (LBA #) in the Node 100 is stored only in the Node # 2001 in which the stripe block 202 constituting each Strip # 2000 is stored, and a predetermined invalid value is stored in the other Node # 2001. Is stored.
  • NEXT 2003 stores a flag to be subjected to stripe update processing in the next processing, and “1” is set to the stripe to be processed next time.
  • the stripe management table 1001 is updated (stripe configuration is updated).
  • processing is performed using the updating stripe management table 1009 in addition to the stripe management table 1001.
  • the fields of the updating stripe management table 1009 are the same as those of the stripe management table 1001 shown in FIG.
  • the updating stripe management table 1009 appropriately stores information indicating the updated stripe configuration during the stripe configuration update processing.
  • the stripe configuration update process is a process executed when a new Node 100 is added to a RAID group, as will be described later, and is a process for distributing Nodes 100 that store parity blocks.
  • FIG. 8 is a diagram illustrating an example of the Node management table 1002.
  • the node management table 1002 is information common to the computer system 1 and information for managing the state of each node 100. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the Node management table 1002 includes a Node # 2010 that stores the identifier of the Node 100 and a Status 2011 field that stores the state of each Node 100.
  • Node # 2010 is an identifier of the Node
  • Status 2011 stores the state of the corresponding Node 100 such as normal (Normal) or failure (Failed).
  • FIG. 9 is a diagram illustrating an example of the drive management table 1003.
  • the drive management table 1003 is information managed for each Node 100, and is information for managing drive information in the Node 100. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the drive management table 1003 includes fields of Pool Volume # 2020, Type 2021, Drive # 2022, Size 2023, and Status 2024 in one entry.
  • Type 2021 stores the type of storage drive 160 such as SSD or NL (Near Line) -SAS.
  • Size 2023 stores the capacity of each storage drive 160 (for example, subblock 200 units).
  • the status 2024 stores the status of each storage drive 160.
  • the Node 100 can acquire the quantity, type, capacity, and state of the storage drive 160 in the Node 100.
  • the status 2024 stores drive states such as “Normal” and “Failed”.
  • the storage drive 160 in which the number of errors exceeds a threshold value is stored.
  • a state such as “Warning” may be stored.
  • FIG. 10 is a diagram showing an example of the Pool Volume management table 1004.
  • the Pool Volume management table 1004 is information common to the computer system 1 and is used by the computer system 1 to manage the capacity of each Pool Volume 211 and the Node 100 in which the Pool Volume 211 exists. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the Pool Volume management table 1004 is assigned a Pool Volume # 2030 that stores an identifier of the Pool Volume 211, a Type 2031 that stores the type of the Pool Volume 211, a Size 2032 that stores the capacity of the Pool Volume 211, and an identifier of the Pool Volume 211.
  • the field of Node # 2033 to be stored is included in one entry.
  • the computer system 1 can acquire the capacity and type of each Pool Volume 211, and the identifier of the Node 100, and when determining which Pool Volume 211 is added to the Pool 210 Used for etc.
  • FIG. 11 is a diagram illustrating an example of the Pool management table 1004.
  • the Pool management table 1005 is information common to the computer system 1 and is used for the management of each Pool 210 by the computer system 1. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the Pool management table 1005 includes the fields of Pool # 2040, Size 2041, Unused 2042, and Pool Volume # 2043 in one entry.
  • Pool # 2040 stores the identifier of the pool 210.
  • the size (the number of blocks) of the entire pool 210 is stored in the Size 2041.
  • Unused 2042 stores the usable capacity (number of blocks) of the size 2041.
  • the identifier of all the Pool Volumes 211 allocated to the Pool 210 is stored in the Pool Volume # 2043.
  • FIG. 12 is a diagram illustrating an example of the VVOL management table 1006.
  • the VVOL management table 1006 is information common to the computer systems 1 and is information indicating a correspondence relationship between the VVOL page 213 and the PoolVol page 214. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the VVOL management table 1006 includes fields of VVOL # 2050, VVOL page # 2052, PoolVol # 2053, and PoolVol page # 2054 in one entry.
  • VVOL # 2050 stores the identifier of the VVOL 212.
  • Size 2051 the capacity (number of blocks) of the VVOL 212 is stored.
  • the VVOL page # 2052 stores the identifier of the VVOL page 213 included in the VVOL.
  • PoolVol # 2052 an identifier of PoolVolume 211 assigned to the VVOL 212 is stored.
  • Pool Vol page # 2054 the identifier of the PoolVol page 214 allocated to the VVOL page 213 is stored.
  • a value corresponding to “unallocated” is stored.
  • the computer system 1 can acquire the usage status of the VVOL 212 and information on the allocation destination.
  • FIG. 13A is a diagram showing an example of the parity Node table 1007.
  • the parity node table 1007 is information common to the computer system 1 and is information used to distribute the Nodes 100 in which parity blocks are stored in the stripe configuration update process described later. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the parity node table 1007 includes fields of an in-cycle index (In-Cycle Index in the figure) # 2060 and a parity node # 2061 in one entry.
  • in-cycle index In-Cycle Index in the figure
  • the stripe configuration update process described later is a periodic process for every N + 2 stripes 203, and in-cycle index # 2060 stores an offset value in the period from 0 to N + 1 as an index in the period.
  • N indicates the number of Nodes 100 including data blocks before adding a new Node 100. In other words, N is the number of data blocks before the Node 100 is expanded.
  • Parity Node # 2061 represents Node 100 in which a parity block is stored in stripe 203 corresponding to the offset value.
  • a process of distributing parity blocks to the five Nodes 100 is performed as described later.
  • the parity blocks are distributed to the newly added Node 100, and the parity blocks are distributed to each Node 100 without overlapping the same Node 100. . That is, in the case of the first embodiment, five processes are one cycle.
  • parity node table 1007 The use of the parity node table 1007 will be described in detail when explaining the stripe configuration update process described later.
  • FIG. 13B is a diagram illustrating an example of an unallocated block management table.
  • the unallocated block management table 1008 is information common to the computer system 1 and is information used for acquiring an area for storing the updated parity block in the stripe configuration update process described later. Information common to the computer system 1 can be referred to from other Node 100 and the management server 20, for example.
  • the unallocated block management table 1008 includes the fields of Node # 2070 and LBA # 2071 in one entry.
  • Node # 2070 stores the identifier of Node 100.
  • LBA # 2071 stores the address of an unallocated block.
  • FIG. 14 is a diagram illustrating an outline of the stripe configuration update process executed when the Node 100 is added according to the first embodiment.
  • Nodes 100-1 to 100-4 (# 0 to An example in which a new Node 100-5 (# 4) is added to the 3D + 1P RAID group configured in # 3) is shown.
  • Nodes 100-1 to 100-5 are described as Node # 0 to Node # 4.
  • Node # 4 to be newly added is set as an extension Node.
  • (1) shows the configuration of the Node 100 immediately after expansion. Specifically, this is a state immediately after 1Node (Node # 4) is added from a state in which a 3D + 1P RAID group is configured by four Nodes # 0 to # 3.
  • Node # 4 a state immediately after 1Node
  • Node # 3 a state in which a 3D + 1P RAID group is configured by four Nodes # 0 to # 3.
  • “Ax”, “Bx”, etc. indicate data blocks
  • Px indicates a parity block.
  • x 0 to n.
  • stripe blocks 202 connected by a bold line in the figure indicate that the stripe blocks 202 constitute one stripe 203.
  • A0, B0, C0, and P0 constitute a stripe 203-0.
  • the added Node (Node # 4) stripe block 202 stores all zeros (predetermined data that does not affect the parity value) or stores zeros internally. Process.
  • the stripe # (number) of the stripe 203 including the stripe block #x of Node # 0 is defined as the stripe #x.
  • x 0 to n. That is, a stripe including A0 is defined as stripe # 0, and a stripe 203 including A1 is defined as stripe # 1.
  • the computer system 1 first calculates and generates an intermediate parity (Pi) from a parity block (P0) of stripe # 0 and a predetermined data block (D1) among Nodes (Node # 3) including the parity block. .
  • the computer system 1 stores the intermediate parity (Pi) as a new parity (P′0) in a predetermined block in the expansion node (Node # 4).
  • the intermediate parity (Pi) is calculated by P0 XOR D1.
  • XOR is an operator that performs an exclusive OR operation. In the following, for simplification, the XOR operator is described using the symbol “+” in the figure.
  • the parity block (P0) excluded (invalidated) from the stripe # 0 due to the reconstruction of the stripe # 0 has information on the block (the identifier of the Node 100 and the position of the block) in the unallocated block management table 1008. Stored.
  • the parity block (P0) excluded from the stripe # 0 is managed as an unallocated stripe block 202.
  • the intermediate parity Pi is exclusive between the parity block (P0) belonging to the stripe # 0 and the data block (D1) newly added to the stripe # 0 with the same Node # 3 as the parity block. Calculate logical OR. Therefore, since it is only necessary to perform a parity operation from the stripe block 202 in the same Node, access between Nodes is unnecessary, and the operation processing can be speeded up.
  • the computer system 1 first obtains an intermediate parity (Pi) from the parity block (P1) of the stripe # 1 and a predetermined data block (C2) among the Nodes (Node # 2) including the parity block by exclusive OR. Generate.
  • the computer system 1 can obtain the position (Node, LBA) of the invalidated parity block (P0) by referring to the unallocated block management table 1008 shown in FIG. 13B.
  • a new parity (P′1) is obtained by exclusive OR of the data block (D1) corresponding to the stripe # 1 and the intermediate parity (Pi). Is stored in the invalid parity block (P0).
  • a new parity (P′1) is calculated as Pi + D1.
  • a predetermined data block (E1) in the extension Node # 4 is defined as a data block of the updated stripe # 1. Since the values of the data blocks of the extension Node # 4 are all 0, the value of the new parity (P′1) does not change.
  • the computer system 1 repeats the same processing below, and updates to the stripe configuration after expansion as shown in (4) of FIG.
  • This process is a periodic process, and the update process of the stripes # 5k to # 5k + 4 (k is an integer equal to or greater than 0), that is, the combination pattern of the stripe blocks 202 is the same as that of the stripes # 0 to # 4. .
  • FIG. 15 is a flowchart showing an example of the Node expansion process.
  • the node expansion processing program 1101 performs stripe configuration update processing when adding the Node 100 to the computer system 1.
  • the administrator adds the node 100 for expansion to the computer system 1 and then inputs an instruction for node expansion (or expansion of the stripe 203) to the management server 20.
  • the management server 20 receives the RAID group (or Node 100) to be added and the extension Node, and transmits an extension command to the Node 100 to be processed.
  • Node # 4 is added to the RAID groups (3D + 1P) of Node # 0 to # 3, but is not limited to this.
  • the management server 20 refers to a table (not shown) indicating the correspondence between the RAID groups and the Node 100 to identify the processing target Node 100. It ’s fine.
  • Each Node 100 executes Node expansion processing when receiving the expansion instruction from the management server 20. Also, each node 100 may automatically execute the node expansion processing program 1101 when the node expansion is detected.
  • any one of the processing target Nodes 100 may become a master, execute the Node expansion processing program 1101, and notify the other Nodes 100.
  • the management server 20 may execute the Node expansion processing program 1101 and notify the processing target Node 100.
  • the Node expansion processing program 1101 selects one Node 100 (Additional Node 100 (# 4)) from among the Nodes 100 to be expanded (Step 3101).
  • the Node expansion processing program 1101 may select the target Nodes in ascending order of the physical Node # in the computer system 1 among the Nodes that are not subjected to the Node expansion processing among the target Nodes of the expansion processing.
  • the Node extension processing program 1101 performs a stripe configuration update process (step 3002).
  • the stripe configuration update process will be described later.
  • the node expansion processing program 1101 determines whether the node expansion processing has been completed for all the expansion nodes added to the computer system 1 (step 3003). If the node expansion processing has not been completed for all the expansion nodes (No in step 3003), the node expansion processing program 1101 returns to step 3001 and performs the same processing for the next target node.
  • the node expansion processing program 1101 ends the process.
  • FIG. 16 is a flowchart showing an example of stripe configuration update processing. This process is the process of step 3002 in FIG. 15, and each Node 100 receives the additional Node 100 and executes the stripe update processing program 1102.
  • the stripe update processing program 1102 generates a stripe pattern after adding the Node 100 and generates a parity block corresponding to the stripe pattern after the addition in Step 3002 of the Node addition processing in FIG.
  • the stripe pattern generation and parity block generation are included in the stripe configuration update processing.
  • the stripe update processing program 1102 refers to the stripe management table 1001 and calculates the number of stripes (S) in the computer system 1 (step 3101).
  • the stripe update processing program 1102 sets the stripe iterator (i) to zero (step 3102).
  • the stripe iterator i means the stripe # (number) currently being processed, and a value from 0 to S-1 is set.
  • the stripe update processing program 1102 performs stripe update processing (cycle) (Step 3104).
  • the stripe update process (cycle) will be described later.
  • the stripe iterator (i) may be synchronized between the Nodes 100 included in the stripe 203 to be updated, for example, at the start of Step 3104.
  • the stripe update processing program 1102 increments the stripe iterator (i) and performs the determination in step 3103 again.
  • the stripe update processing program 1102 determines whether there is an unupdated stripe 203, that is, whether the stripe iterator (i) is less than S. A determination is made (step 3106).
  • step 3103 it is determined whether or not the number of unupdated stripes (Si) is less than the stripe update processing cycle (n + 2). If the number of unupdated stripes is less than the period, a determination is made in step 3106 as to whether or not the number of unupdated stripes includes a fraction that is less than the period.
  • the stripe update processing program 1102 performs stripe update processing (fraction) (Step 3107).
  • the stripe update process (fraction) will be described later.
  • the stripe update processing program 1102 increments the stripe iterator (i) and performs the determination in step 3106 again.
  • the stripe update processing program 1102 ends the process and returns to the process of FIG.
  • the stripe update processing (cycle) in step 3104 is executed, and the number of unupdated stripes is less than the cycle. Then, the process is switched to the stripe update process (fraction) in step 3107.
  • FIG. 17 is a flowchart showing an example of the stripe update process (cycle).
  • the stripe update process (cycle) is performed as a part of the stripe update process program 1102, and a stripe pattern of each stripe 203 is generated in step 3104 of the stripe update process shown in FIG.
  • the stripe pattern generates a periodic pattern for leveling the arrangement of parity blocks between the Nodes 100.
  • the stripe update processing program 1102 refers to the stripe iterator (i) and calculates the value of i mod (n + 2) (step 3201).
  • n represents the number of data blocks in the stripe before expansion.
  • “Mod” indicates a function for calculating a remainder obtained by dividing i by n + 2.
  • the stripe update processing program 1102 performs a stripe update process (period head) (step 3202).
  • the stripe update process (mid-cycle) will be described later.
  • the stripe update process (cycle) 3104 performs the stripe update process (mid-cycle) (step 3203).
  • the stripe update process (mid-cycle) will be described later.
  • the stripe update processing program 1102 performs stripe update processing (before the end of the cycle) (step 3204).
  • the stripe update process (before the end of the cycle) will be described later.
  • the stripe update processing program 1102 performs stripe update processing (period end) (step 3205).
  • the stripe update process (period end) will be described later.
  • step 3203 the stripe block 202 of the stripe 203 is updated for the stripe # 1.
  • step 3203 the stripe block 202 of the stripe 203 is updated for the stripe # 2.
  • the stripe block 202 of the stripe 203 is updated for the stripe # 3.
  • the stripe block 202 of the stripe 203 is updated for the stripe # 4.
  • the update processing of the stripe 203 for distributing the parity blocks to Node # 0 to # 4 is repeatedly executed as one cycle. To do.
  • FIG. 18 shows a stripe update process (period head).
  • the stripe update process (period head) is performed as a part of the stripe update process program 1102, and the stripe update process is performed on the stripe 203 corresponding to the head of the stripe update process period among the stripes 203.
  • stripe # 0 is the beginning of the cycle.
  • the stripe update processing program 1102 acquires the next processing stripe (Sn: “S” represents “Stripe” and “n” represents “next”) (step 3301).
  • the next processing stripe (Sn) represents the stripe 203 that performs the update processing of the stripe configuration next.
  • stripe update processing program 1102 refers to the stripe management table 1001 for the first processing, and sets the first Stripe # 2000 as the next processing stripe (Sn).
  • the stripe update processing program 1102 refers to the stripe management table 1001 and sets Stripe # 2000 next to the previous stripe update processing as the next processing stripe (Sn). In addition, the process is started after the in-cycle index # 2060 is reset to “0”.
  • the stripe management table 1001 or the updating stripe management table 1009 may be referred to, and a predetermined stripe 203 may be selected from the unupdated stripes 203, but in order to simplify the process In addition, it is desirable to select the unprocessed stripe 203 having the smallest stripe # 2000.
  • the stripe update processing program 1102 stores a node (Np: Np :) in which a parity block (Po: “P” represents “Parity” and “o” represents “old”) in the next processing stripe (Sn).
  • the identifier (# 0 to #n) of “N” represents “Node” is acquired.
  • Node 100 including a parity block (Po) is referred to as a parity node (Np).
  • the stripe update processing program 1102 sets “0” indicating the beginning of the cycle to the in-cycle index # 2060 of the parity node table 1007, and registers the identifier of the acquired parity node (Np) in the parity node 2061 (step 3302). ).
  • the parity node table 1007 is referred to when an intermediate parity generation block is selected in a stripe update process (mid-period) 3203 described later.
  • Step 3303 the processing after Step 3303 is executed by the parity node (Np) and the additional Node 100 that has received the intermediate parity from the parity node (Np).
  • the Node 100 other than the parity node (Np) and the additional Node 100 waits until receiving a process completion notification from the parity node (Np).
  • the stripe update processing program 1102 of the parity node (Np) stores a predetermined stripe block (Bd: “B” represents “Block” and “d” represents “data”) 202 in the parity node (Np). Select (step 3303).
  • the stripe block (Bd) may select a predetermined stripe block in the parity node Np. However, in order to simplify the process, the stripe block 202 in the parity node (Np) is not updated and the LBA It is desirable to select the one with the smallest.
  • the stripe update processing program 1102 determines whether or not the selected stripe block (Bd) is (1) unallocated in the new stripe configuration and (2) a data block instead of a parity block. Determination is made (step 3304).
  • the stripe update processing program 1102 of the parity node (Np) returns to Step 3303 and selects a different stripe block (Bd) again.
  • the stripe update processing program 1102 sets the stripe 203 corresponding to the selected stripe block (Bd) on the stripe management table 1001 before addition as the next processing stripe. As shown in FIG. 7, a flag is registered in NEXT 2003 of the stripe management table 1001 (step 3305).
  • the stripe update processing program 1102 generates an intermediate parity (Pi: “i” represents “intermediate”) from the parity block (Po) and the stripe block (Bd) on the parity node (Np) and adds them. Transfer to Node (Na: “a” represents “additional”) (step 3306).
  • the intermediate parity (Pi) is calculated by Po XOR Bd.
  • the stripe update processing program 1102 receives the intermediate parity (Pi) from the parity node (Np).
  • the stripe update processing program 1102 of the expansion node (Na) selects a predetermined stripe block (Ba) in the expansion node (Na) and stores the intermediate parity (Pi) (step 3307).
  • the intermediate parity (Pi) becomes a parity block as it is.
  • a predetermined stripe block in the expansion node (Na) may be selected.
  • the LBA is the largest among the stripe blocks in the expansion node (Na). It is desirable to select a small one.
  • the stripe update processing program 1102 of the parity node (Np) is stored in the node 100 other than the parity node (Np) and the added node (Na) in the next processing stripe Sn on the stripe management table 1001 before the addition.
  • the total n + 1 stripe blocks of the n data blocks, the stripe block (Bd), and the stripe block Ba (parity) are stored in the updating stripe management table 1009 as stripe blocks having a new stripe configuration, and the stripe The configuration is updated (step 3308).
  • the stripe update processing program 1102 sets the parity block (Po) selected in step 3302 as an unallocated block (Bn: “n” represents “non-allocated”) in the unallocated block management table 1008. Register and end the stripe update process at the beginning of the cycle.
  • the stripe update processing program 1102 of the parity node (Np) Since the processing of the first stripe 203 of the cycle is completed, the stripe update processing program 1102 of the parity node (Np) notifies the other Node 100 in the stripe 203 of the completion of the processing and increments the value of the index # 2060 in the cycle. To do. Also, the stripe update processing program 1102 of the parity node (Np) transmits the difference between the stripe management table 1001, the parity node table 1007, the unallocated block management table 1008, and the updating stripe management table 1009 to other nodes 100. And synchronize.
  • the intermediate parity (Pi) is written in the stripe block that satisfies a predetermined condition (for example, LBA is minimum) among the unprocessed stripe blocks (Ba), and remains as it is. Let it be a parity block.
  • a predetermined condition for example, LBA is minimum
  • FIG. 19 is a flowchart showing an example of stripe update processing (intermediate period).
  • stripe update process (period middle) in FIG. 19
  • stripe update process in FIG. 20 (before the cycle end)
  • stripe update process (cycle end) in FIG. 21 are the stripe update process (cycle start) in FIG. 18. Since only some of the processes overlap, only the differences will be described.
  • the stripe update process (intermediate period) is executed as part of the stripe update process program 1102 in step 3203 of FIG. 17 to update the stripe configuration other than the stripe corresponding to the head, before the end, and the end of each stripe period. Do. In FIG. 14, stripes # 1 and # 2 are the middle of the cycle.
  • the stripe update processing program 1102 acquires the next processing stripe (Sn) (step 3401).
  • the stripe update process (intermediate period)
  • the stripe 203 registered in the stripe management table 1001 is selected as the next process stripe.
  • the stripe update processing program 1102 refers to the stripe management table 1001 and selects the stripe # 2000 of the entry in which “1” is set in NEXT 2003 as the next processing stripe (Sn).
  • the stripe update processing program 1102 resets NEXT 2003 of the entry to “0”.
  • Step 3402 and Step 3403 are respectively the same as Step 3302 and Step 3303 in the stripe update processing (period head) of FIG. That is, the stripe update processing program 1102 acquires the parity block (Po), the parity node (Np), and the stripe block (Bd), and updates the parity Node table 1007.
  • the stripe update processing program 1102 acquires the parity block (Po), the parity node (Np), and the stripe block (Bd), and updates the parity Node table 1007.
  • the processing after step 3403 is executed by the parity node (Np) and the node (Nn) that has received the intermediate parity from the parity node (Np).
  • the Node 100 other than the parity node (Np) and the node (Nn) waits until it receives a process completion notification from the parity node (Np).
  • the stripe update processing program 1102 determines that the selected stripe block (Bd) is (1) unallocated in the new stripe configuration, and (2) a data block instead of a parity block, and (3 ) On the stripe management table 1001 before the addition, it is determined whether or not the node 100 in which the parity block is stored in the stripe 203 to which the stripe block (Bd) belongs exists in the parity node table 1007 (step 3404).
  • the stripe update processing program 1102 returns to Step 3403 and selects a different stripe block (Bd) again.
  • Step 3405 is the same as step 3305 in the stripe update processing (period head) in FIG. That is, the stripe update processing program 1102 sets NEXT 2003 of the corresponding entry of the stripe management table 1001 to “1”.
  • the stripe update processing program 1102 generates an intermediate parity (Pi) from the exclusive OR of the parity block (Po) and the stripe block (Bd) at the parity node (Np). Then, the stripe update processing program 1102 transfers the intermediate parity (Pi) to the Node (Nn) where the unallocated block (Bn) exists (step 3406).
  • the stripe update processing program 1102 of the parity node (Np) uses the unassigned block management table 1008 as an intermediate parity with the value of Node # 2070 as the transfer destination Node (Nn) and LBA # 2071 as the unassigned block (Bn). Transfer (Pi).
  • the stripe update processing program 1102 of the parity node (Np) clears the entry read in the unallocated block management table 1008.
  • the stripe update processing program 1102 of the transfer destination Node (Nn) receives the received intermediate parity (Pi) and the transfer destination Node (Nn) corresponding to the next processing stripe (Sn) on the stripe management table 1001 before addition.
  • a new parity (Pn: “n” represents “new”) is generated from the internal data block (Bo).
  • the stripe update processing program 1102 of the transfer destination Node (Nn) stores the new parity (Pn) in the area of the unallocated block (Bn) (Step 3407).
  • the new parity (Pn) is calculated by Bo XOR Pi.
  • the stripe update processing program 1102 generates a new parity (Pn) from the exclusive OR of the intermediate parity (Pi) and the data block (D1).
  • the stripe update processing program 1102 instructs the extension node (Na) to select a predetermined unallocated stripe block (Ba) in the extension node (Na) (step 3408).
  • the stripe block 202 in the extension node Na may be selected.
  • the stripe block 202 in the extension node Na is not allocated and the LBA is It is desirable to select the smallest one.
  • the stripe update processing program 1102 of the parity node (Na) includes the parity node (Np), the extension node (Na), and the transfer destination node (of the next processing stripe Sn on the stripe management table 1001 before the addition.
  • the updated stripe management table 1009 is updated as the stripe block of the updated stripe Sn (step 3409).
  • Step 3410 is the same as Step 3309 in the stripe update processing (cycle head) of FIG.
  • the stripe update processing program 1102 of the parity node (Np) Since the processing of the stripe 203 in the middle of the cycle is completed, the stripe update processing program 1102 of the parity node (Np) notifies the other Node 100 in the stripe 203 of the completion of the processing and increments the value of the index # 2060 in the cycle. To do. Also, the stripe update processing program 1102 of the parity node (Np) transmits the difference between the stripe management table 1001, the parity node table 1007, the unallocated block management table 1008, and the updating stripe management table 1009 to other nodes 100. And synchronize.
  • stripe blocks A1, B1, C2, P′1, and E1 and registered in the updating stripe management table 1009 by the above processing.
  • the intermediate parity (Pi) generated at the node # 2 is only transferred to the parity block P′1 of the node # 3.
  • Other stripe blocks A1, B1, and C2 are held at their previous positions without moving.
  • the intermediate parity (Pi) generated at the node # 1 is only transferred to the parity block P′2 of the node # 2.
  • the other stripe blocks A2, B3, P′2, D2, and E2 are held at the previous positions without moving.
  • FIG. 20 is a flowchart showing an example of the stripe update process (before the end of the cycle).
  • the stripe update processing (before the end of the cycle) is performed as part of the stripe update processing program 1102 in step 3204 in FIG. 17, and the configuration is updated with the stripe immediately before the end of each stripe cycle.
  • steps 3501, 3503, and 3504 are the same as steps 3301, 3303, and 3304 of the stripe update process (cycle start). Except for steps 3502 and 3504, the stripe update process (cycle (Middle).
  • step 3502 the stripe update processing program 1102 acquires the parity node (Np) in which the parity block (Po) in the next processing stripe (Sn) is stored.
  • the stripe update process program 1102 selects the next process stripe (Sn) appropriately, so that the acquired parity node (Np) is the parity node. Although registered in the table 1007, in the stripe update process (before termination), since the next process stripe (Sn) is uniquely determined, registration in the parity node table 1007 is unnecessary.
  • the next processing stripe (Sn) may be selected from the stripe management table 1001 with the stripe update processing program 1102 selected from the stripe management table 1001 with the next stripe after the stripe 203 processed in the stripe update processing (mid-period) shown in FIG. Good.
  • step 3503 is executed by the parity node (Np) and the node (Nn) that received the intermediate parity from the parity node (Np).
  • the Node 100 other than the parity node (Np) and the node (Nn) waits until it receives a process completion notification from the parity node (Np).
  • Steps 3505 to 3510 are the same as Steps 3405 to 3410 of the stripe update processing (period head) shown in FIG.
  • the stripe update processing program 1102 of the parity node (Np) Since the processing of the stripe 203 immediately before the end of the cycle is completed, the stripe update processing program 1102 of the parity node (Np) notifies the other Nodes 100 in the stripe 203 of the completion of the processing and the index # 2060 of the in-cycle index # 2060. Increment the value. Also, the stripe update processing program 1102 of the parity node (Np) transmits the difference between the stripe management table 1001, the parity node table 1007, the unallocated block management table 1008, and the updating stripe management table 1009 to other nodes 100. And synchronize.
  • the intermediate parity (Pi) generated at the node # 0 is only transferred to the parity block P′3 of the node # 1.
  • the other stripe blocks A4, C3, D3, and E3 are held at their previous positions without moving.
  • FIG. 21 is a flowchart showing an example of stripe update processing (period end).
  • the stripe update process (period end) is performed as part of the stripe update process program 1102 in step 3205 of FIG. 17 to update the stripe configuration at the end of each stripe period.
  • step 3601 the stripe update processing program 1102 executes step 3601.
  • step 3601 the next stripe after the stripe 203 processed in the stripe update process (before the end of the cycle) in FIG. 20 is selected from the stripe management table 1001 as a processing target.
  • the stripe update processing program 1102 changes the parity block (Po) in the next processing stripe (Sn) to a data block (Bc: “c” represents “changed”) (stripe 3602).
  • the parity block (Po) including the added Node # 4 is to be distributed and stored in each Node 100, at least one stripe of the parity block (Po) is stored in the added Node within the cycle. This is because it is necessary to change the parity block of at least one stripe into a data block (performed in the stripe update processing (cycle head)) within the cycle.
  • Step 3602 the processing after Step 3602 is executed by the parity node (Np) and the transfer destination node (Nn) that received the intermediate parity from the parity node (Np).
  • the Node 100 other than the parity node (Np) and the transfer destination node (Nn) waits until it receives a process completion notification from the parity node (Np).
  • the stripe update processing program 1102 transfers the data block (Bc) to the transfer destination node (Nn) where the unallocated block exists (step 3603).
  • the stripe update processing program 1102 transfers the data block (Bc) on the transfer destination node (Nn) and the transfer destination node (Nn) corresponding to the next processing stripe (Sn) on the stripe management table 1001 before the addition. ) To generate a new parity (Pn: “n” represents “new”).
  • the stripe update processing program 1102 stores the generated new parity (Pn) in the area where the unallocated block (Bn) was stored (step 3604).
  • the new parity (Pn) is calculated by Bo XOR Bc.
  • the next step 3605 is the same as step 3408 in the stripe update process (mid-period) in FIG. That is, the stripe update processing program 1102 instructs the extension node (Na) to select a predetermined unallocated stripe block (Ba) in the extension node (Na). The extension node (Na) responds with the position (LBA) of the selected stripe block 202.
  • the stripe update processing program 1102 sets a node other than the parity node (Np), the additional node (Na), and the transfer destination node (Nn) in the next processing stripe (Sn) on the stripe management table 1001 before the addition.
  • a total of n + 1 stripe blocks of n-1 data blocks and Bc, Ba, Bn (parity) stored are selected as the stripe block 202 of the next processing stripe (Sn) on the new stripe, and the stripe being updated
  • the management table 1009 is updated (step 3606).
  • the stripe update processing program 1102 clears the parity node table 1007 and the next processing stripe of NEXT 2003 in the stripe management table 1001, and ends the processing (step 3607).
  • the stripe update processing program 1102 of the parity node (Np) Since the processing of the stripe 203 at the end of the cycle is completed, the stripe update processing program 1102 of the parity node (Np) notifies the other Node 100 in the stripe 203 of the completion of the processing and increments the value of the in-cycle index # 2060. To do. Also, the stripe update processing program 1102 of the parity node (Np) transmits the difference between the stripe management table 1001, the parity node table 1007, the unallocated block management table 1008, and the updating stripe management table 1009 to other nodes 100. And synchronize.
  • the stripe # 4 is selected as the next processing stripe at the end of the cycle and the parity block P4 of the node # 3 is selected as the parity block (Po) as shown in (3) in the example of FIG.
  • the parity block P4 is rewritten to the data block D4.
  • the value of the data block D4 to be rewritten is set to “0” which is a predetermined value.
  • the new parity (Pn) of the node (Nn) is stored in the updating stripe management table 1009 as the stripe block 202 of the new stripe # 4.
  • FIG. 22 is a flowchart showing an example of stripe update processing (fraction). This process is executed in step 3107 in FIG.
  • the stripe update processing (fraction) is executed as part of the stripe update processing program 1102 and, among the stripes to be processed in the computer system 1, the update of the stripe 203 with a fraction less than the stripe configuration update period (n + 2) is performed. I do.
  • Stripe update processing differs depending on whether the number of stripes is 1 or not. Therefore, first, the stripe update processing program 1102 calculates the number of stripes as a fraction (step 3701). Specifically, it may be determined whether or not S mod (n + 2) is 1.
  • the stripe update processing program 1102 performs a stripe update process (fraction 1) (step 3702).
  • the stripe update process (fraction 1) will be described later.
  • the stripe update processing program 1102 performs a stripe update process (fraction 2 or more) (step 3703).
  • the stripe update process (fractional number 2 or more) will be described later.
  • FIG. 23 is a flowchart showing an example of the stripe update process (fraction 1). This process is executed in step 3702 of FIG.
  • the stripe update processing (fraction) is performed as a part of the stripe update processing program 1102, and, out of the stripes 203 to be processed in the computer system 1, the number of stripes with a fraction less than the number of stripe configuration update cycles is 1 In this case, the fractional stripe configuration is updated (fractional 1).
  • the stripe update processing program 1102 selects an unallocated stripe block (Ba) on the expansion node (Na) (step 3801).
  • the stripe update process fraction 1
  • the unassigned stripe block (Ba) is uniquely determined.
  • the stripe update processing program 1102 stores a total of n + 1 data blocks and parity blocks (Po) corresponding to the next processing stripe (Sn) on the stripe management table 1001 before addition, and an unallocated stripe block (Ba).
  • the in-update stripe management table 1009 is updated with a total of n + 2 stripe blocks as the stripe block 202 of the next processing stripe (Sn) of the new stripe configuration (step 3802), and the processing is terminated.
  • the parity block (Po) on the stripe management table 1001 before the addition can use the same value after the update.
  • FIG. 24 is a flowchart showing an example of stripe update processing (fractional number 2 or more). This process is executed in step 3703 of FIG.
  • the stripe update process (fractional number 2 or more) is performed as part of the stripe update processing program 1102 and, out of the stripes 203 to be processed in the computer system 1, the number of fractional stripes that is less than the number of update periods (n + 2) of the stripe configuration
  • the fractional stripe configuration is updated when the number of is more than two.
  • the stripe update processing program 1102 refers to the stripe iterator (i) and calculates the value of i mod (n + 2) (step 3901).
  • the stripe update processing program 1102 performs the stripe update processing (period head) shown in FIG. 18 (step 3902).
  • the stripe update processing program 1102 shown in FIG. 19 performs stripe update processing (mid-period) (step 3903).
  • the stripe update processing program 1102 performs the stripe update processing (before the end of the cycle) shown in FIG. 20 (step 3904).
  • the stripe update processing program 1102 performs the stripe update processing (period end) shown in FIG. 21 (step 3905).
  • the stripe configuration is updated for the stripes 203 having a fraction less than the stripe configuration update period (n + 2).
  • FIG. 25 is a flowchart illustrating an example of rebuild processing when a Node failure occurs according to the first embodiment.
  • the rebuild process program 1103 is automatically executed when the computer system 1 detects a failure of any Node 100. Alternatively, after a failure occurs in any of the Nodes 100, the process is executed according to an instruction from the management server 20.
  • a spare Node 100 hereinafter referred to as a spare Node
  • the rebuild processing program 1103 acquires the identifier of the node 100 in which the failure has occurred as the failure node # (step 4001).
  • the rebuild process program 1103 acquires the rebuild target stripe number as Stripe # (step 4002).
  • the stripe # to be rebuilt the stripe 203 with the smallest stripe # is selected from the stripes 203 that have not been rebuilt.
  • the rebuild processing program 1103 refers to the stripe management table 1001 and acquires the LBA of the stripe block in each Node corresponding to the Stripe # (step 4003).
  • the rebuild processing program 1103 transfers the plurality of data (data block and parity block) specified by the LBA in Step 4003 from each Node 100 to the spare Node, and restores the lost data (Step 4004).
  • the rebuild processing program 1103 stores the restored data in a predetermined area in the spare node and updates the stripe management table 1001 (step 4005).
  • the rebuild processing program 1103 updates the copy pointer 1010 (step 4006).
  • the copy pointer 1010 is a variable used for determining whether to acquire target data from a spare node or by collection read in response to a Read request issued from the host 10, for example. .
  • the data is in a stripe having a stripe # larger than the copy pointer 1010 and the corresponding node 100 is in a failure state on the node management table 1002, the data other than the target data is restored according to the stripe management table 1001. After obtaining a certain number of stripe blocks necessary for the recovery and performing the recovery process, it is sufficient to respond to the request source.
  • the rebuild processing program 1103 determines whether or not the rebuild processing of the stripe 203 to be restored has been completed (step 4007). If the rebuild process for the recovery target stripe 203 has not been completed (No in step 4007), the process returns to step 4002 to reselect the rebuild target Stripe #. If the rebuild process for the recovery target stripe 203 is completed (Yes in step 4007), the process ends.
  • the stripe update processing program 1102 transfers at least one stripe block 202 to another Node 100 for one stripe 203. By moving, the stripe configuration can be updated.
  • the stripe update processing program 1102 generates an intermediate parity in one Node 100, transfers the parity block of the intermediate parity to the other Node 100, and the Node 100 that has received the intermediate parity has the intermediate parity.
  • a new parity is generated with the existing data in Node100.
  • the data movement amount between the Nodes 100 can be reduced to 1 / N of the total capacity (N is the number of Nodes in the system). It becomes possible. As a result, even in a scale-out configuration where the network bandwidth between the Nodes 100 is narrow, capacity efficiency can be improved at high speed.
  • FIG. 26 is a block diagram illustrating an example of the management server 20 according to the second embodiment.
  • the management server 20 performs the stripe update processing program 1102 mainly. Show.
  • the management server 20 includes a CPU 21 that performs arithmetic processing, a memory 22 that stores programs and data, and a management I / F 23 that is connected to each Node 100 via the network 30.
  • control program storage area 222 for storing various programs and a control information storage area 221 for storing various information are set.
  • the control program storage area 222 stores a Node extension processing program 1101, a stripe update processing program 1102, and a rebuild processing program 1103, which are the same as those in the first embodiment.
  • the I / O processing program 1104 shown in the first embodiment is executed on each Node 100.
  • the control information storage area 221 includes a stripe management table 1001, a Node management table 1002, a drive management table 1003, a Pool Volume management table 1004, a Pool management table 1005, and a VVOL management table 1006 as in the first embodiment.
  • the parity node table 1007, the updating stripe management table 1009, the unallocated block management table 1008, and the copy pointer 1010 are stored.
  • parity node table 1007 the unallocated block management table 1008, and the copy pointer 1010 are set for each node 100.
  • the management server 20 executes the Node extension processing program 1101 and the stripe update processing program 1102 and instructs each Node 100 to update the stripe configuration when the Node 100 is added.
  • the contents of the processing are the same as those in the first embodiment, and the description is omitted.
  • N is the number of Nodes in the system.
  • the present invention can be applied regardless of whether a node is configured by a computer or a storage drive that provides a storage area.
  • stripe update processing may be performed at each Node 100 or the management server 20 as in the first and second embodiments.
  • the processor that controls the node may perform update processing of a stripe configured by a plurality of storage drives.
  • this invention is not limited to each above-mentioned Example, Various modifications are included.
  • the above-described embodiments are described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment.
  • any of the additions, deletions, or substitutions of other configurations can be applied to a part of the configuration of each embodiment, either alone or in combination.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • each of the above-described configurations, functions, and the like may be realized by software by the processor interpreting and executing a program that realizes each function.
  • Information such as programs, tables, and files for realizing each function can be stored in a recording device such as a memory, a hard disk, and an SSD, or a recording medium such as an IC card, an SD card, and a DVD.
  • control lines and information lines indicate what is considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.

Abstract

プロセッサと、メモリと、記憶領域とを含むノードを複数有し、前記プロセッサは、前記ストライプの更新処理を行う場合に、第１のノードに含まれるデータブロックと、前記第１のノードに含まれかつ処理対象ストライプに含まれるパリティブロックとから、中間パリティを生成し、前記中間パリティを、第２のノードに転送し、前記第２のノードのブロックにパリティとして格納させ、前記中間パリティを生成する基となったデータブロックと、前記パリティを格納したブロックと、前記第１及び第２のノード以外の処理対象ストライプ内のデータブロックと、でストライプを構成する。

Description

ストレージシステム及びストレージシステムの制御方法
　本発明は、ストレージシステムに関する。
　ＩＴ投資額が横ばいになる一方で、データ量の増大化が進んでいる。ストレージシステムのコスト低減がますます重要となってきている。
　例えば、分散型ストレージシステムの一つとして、多数の汎用サーバをネットワークにより接続しストレージプールを生成する、ＳｅｒｖｅｒＳＡＮ型ストレージシステムが、将来に普及すると見られている。特に、大規模なビッグデータ分析等のためにサーバＮｏｄｅに高速なＳＳＤを搭載して高性能な分析を狙うシステムにおいて、ＳｅｒｖｅｒＳＡＮ型ストレージシステムは、有効なソリューションであると考えられる。
　また、複数のストレージ装置（Ｎｏｄｅ）により、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙ　ｏｆ　Ｉｎｅｘｐｅｎｓｉｖｅ（またはＩｎｄｅｐｅｎｄｅｎｔ）　Ｄｉｓｋｓ）グループを構成し、ＲＡＩＤグループに基づいて生成された論理ボリュームを、上位装置（例えばホストコンピュータ）へ提供するストレージシステムが知られている。
　このような冗長構成のストレージシステムでは、ＲＡＩＤグループのビットコスト、即ち容量効率はＲＡＩＤを構成するデータブロック数と冗長化のための保護ブロック（ミラーブロック、またはパリティブロック）数の比率によって決まる。ＲＡＩＤ５、またはＲＡＩＤ６の構成において、データブロック（Ｄ）の数をｎとし、パリティブロック（Ｐ）の数をｍとするストライプ構成、即ちｎＤ＋ｍＰで構成されたＲＡＩＤグループの容量効率は、ｎ／（ｎ＋ｍ）となる。例えば、３Ｄ＋１Ｐ（ＲＡＩＤ５）で構成されたＲＡＩＤグループの容量効率は、３／（３＋１）＝７５％である。
　本技術分野の背景技術として、特許文献１には、ＳｅｒｖｅｒＳＡＮ型ストレージシステムにおいて、Ｗｒｉｔｅデータを各Ｎｏｄｅへ適切に分散配置することで、リードレイテンシを削減しつつ高信頼なシステムを構築する方法が開示されている。
　また、本技術分野の他の背景技術として、特許文献２には、既存のＲＡＩＤグループを拡張することにより、システムの容量効率を改善する方法が開示されている（例：３Ｄ＋１Ｐ→４Ｄ＋１Ｐ）。
国際公開第２０１６／０５１５１２号 特開２０１０－６６８３２号公報
　特許文献１では、ＲＡＩＤグループ構成（ストライプ構成とも呼称する）を維持したＮｏｄｅ増設方法が開示されている。近年では、ストレージシステムの導入コストを削減するため、小規模構成で運用を開始（スモールスタート）し、事業規模等に応じて順次Ｎｏｄｅを増設していく運用ケースが増加している。
　しかしながら、小規模構成で運用を開始し、特許文献１に記載の方法でＮｏｄｅ増設を行った場合、Ｎｏｄｅ数が増加しても容量効率の高いストライプ構成での運用ができないという課題があった。
　具体的には、例えば、Ｎｏｄｅ数を３で運用を開始した場合、ストライプを構成する各データは全て異なるＮｏｄｅ内に格納しなければならないというＲＡＩＤ５の制約から、２Ｄ＋１Ｐ（容量効率６７％）が最も容量効率のよいストライプ構成となる。
　一方で、Ｎｏｄｅ数を１０で運用を開始した場合、９Ｄ＋１Ｐ（容量効率９０％）といった容量効率の高いストライプ構成での運用も可能であるが、前述の通り、Ｎｏｄｅ数が３から増設を繰り返してＮｏｄｅ数が１０となった場合、容量効率６７％の状態で運用を継続せざるを得ない。
　また、特許文献２では、ストライプ構成を拡張することにより、システムの容量効率を改善する方法が開示されている。しかし、特許文献２に記載の方法では、システム内に格納されている全データの再配置が必要となる。特に、本発明の主な対象であるＳｅｒｖｅｒＳＡＮ型のストレージシステム、すなわちＳｃａｌｅ－ｏｕｔ型のシステムでは、一般的にＮｏｄｅ間の帯域がストレージ内部の帯域に比べて狭いことが多く、ストライプ構成の拡張処理が完了するまでに膨大な時間を要してしまうという課題があった。
　そこで本発明は、ストライプ構成を拡張する際に、Ｎｏｄｅ間でのデータの移動量を削減して、ノードの増設処理を高速化することを目的とする。
　本発明は、プロセッサと、メモリと、記憶領域とを含むノードを複数有し、複数の前記ノードでデータブロックとパリティブロックとを含んでストライプを構成するストレージシステムであって、前記プロセッサは、前記ストライプの更新処理を行う場合に、第１のノードに含まれるデータブロックと、前記第１のノードに含まれかつ処理対象ストライプに含まれるパリティブロックとから、中間パリティを生成し、前記中間パリティを、第２のノードに転送し、前記第２のノードのブロックにパリティとして格納させ、前記中間パリティを生成する基となったデータブロックと、前記パリティを格納したブロックと、前記第１及び第２のノード以外の処理対象ストライプ内のデータブロックと、でストライプを構成する。
　本発明によれば、ストライプの構成を拡張する際にＮｏｄｅ間のデータ移動量を削減する。これにより、Ｓｃａｌｅ－ｏｕｔ構成において、データの再配置の移動量を低減して高速に容量効率を改善することができる。
本発明の実施例１を示し、計算機システムのハードウェア構成の一例を示すブロック図である。 本発明の実施例１を示し、キャッシュメモリの制御情報格納領域の一例を示すブロック図である。 本発明の実施例１を示し、キャッシュメモリの制御プログラム格納領域の一例を示すブロック図である。 本発明の実施例１を示し、記憶ドライブのデータ構成の一例を示すブロック図である。 本発明の実施例１を示し、ＲＡＩＤグループ構成の一例を示す図である。 本発明の実施例１を示し、ＲＡＩＤグループ構成のデータ配置の一例を示す図である。 本発明の実施例１を示し、計算機システムの記憶領域の論理構成の一例を示す図である。 本発明の実施例１を示し、ストライプ管理テーブルの一例を示す図である。 本発明の実施例１を示し、Ｎｏｄｅ管理テーブルの一例を示す図である。 本発明の実施例１を示し、ドライブ管理テーブルの一例を示す図である。 本発明の実施例１を示し、Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブルの一例を示す図である。 本発明の実施例１を示し、Ｐｏｏｌ管理テーブルの一例を示す図である。 本発明の実施例１を示し、ＶＶＯＬ管理テーブルの一例を示す図である。 本発明の実施例１を示し、パリティＮｏｄｅテーブルの一例を示す図である。 本発明の実施例１を示し、未割当ブロック管理テーブルの一例を示す図である。 本発明の実施例１を示し、Ｎｏｄｅ増設時のストライプ構成の更新処理の概要を示す図である。 本発明の実施例１を示し、Ｎｏｄｅ増設処理の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（周期）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（周期先頭）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（周期中盤）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（周期終端前）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（周期終端）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（端数）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（端数＝１）の一例を示すフローチャートである。 本発明の実施例１を示し、ストライプ構成の更新処理（端数２以上）の一例を示すフローチャートである。 本発明の実施例１を示し、Ｎｏｄｅ障害時のリビルド処理の一例を示すフローチャートである。 本発明の実施例２を示し、管理サーバの構成の一例を示すブロック図である。
　以下、本発明の一実施形態について添付図面を用いて説明する。
　なお、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶこともできる。
　また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インタフェースデバイス（例えばポート）を用いながら行うため、処理の主語がプログラムとされても良い。
　プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機（例えば、管理計算機、ホスト計算機、コントローラ等）が行う処理としても良い。また、コントローラ（ストレージコントローラ）は、プロセッサそれ自体であっても良いし、コントローラが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。プログラムは、プログラムソースから各コントローラにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又はコンピュータ読取可能な記憶メディアであっても良い。
　また、以下の説明では、要素の識別情報として、ＩＤが使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号又は参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用又は参照符号に代えてその要素に割り振られたＩＤを使用することがある。
　また、以下の説明では、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。
　本実施例１に係るストレージシステムを含む計算機システムの概要を説明する。図１は、本実施例１に係る計算機システムのハードウェア構成の一例を示すブロック図である。
　計算機システム１は、１以上のホスト計算機（以下、ホストという）１０と、管理サーバ２０と、複数のＮｏｄｅ１００－１～１００ｎとを含む。ホスト１０と、管理サーバ２０と、Ｎｏｄｅ１００－１～１００ｎとは、ネットワーク１５０を介して接続されている。なお、Ｎｏｄｅ１００の個々を特定しない場合には、「－」以降を省略した符号「１００」を用いる。他の構成要素の符号についても同様である。
　ネットワーク１５０は、ローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）であっても良く、ワイドエリアネットワーク（ＷＡＮ：Ｗｉｄｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）であってもよい。また、ホスト１０とＮｏｄｅ１００が一つの計算機であってもよい。また、ホスト１０とＮｏｄｅ１００－１～１００ｎのそれぞれが仮想マシンであってもよい。
　ホスト１０は、例えば、アプリケーションを実行する計算機であり、アプリケーションにより利用されるデータをＮｏｄｅ１００から読み出し、アプリケーションにより生成されたデータをＮｏｄｅ１００へ書き込む。
　管理サーバ２０は、管理者によって使用される計算機である。管理サーバ２０は、情報を入力するための入力デバイス（図示省略）と、情報を表示するための出力デバイス（図示省略）とを含んでもよい。管理サーバ２０は、入力デバイスに対する管理者の操作により、Ｎｏｄｅ１００の増設または縮退時のデータの再配置処理の設定を受け付け、Ｎｏｄｅ１００に受け付けたデータの再配置処理を実行させる。
　Ｎｏｄｅ１００は、１以上のポート１１０と、１以上の管理Ｉ／Ｆ１２０と、１以上のＣＰＵ１３０と、１以上のキャッシュメモリ（図中ＣＭ：Ｃａｃｈｅ　Ｍｅｍｏｒｙ）１４０と、１以上の記憶ドライブ１６０と、内部ネットワーク１５０とを有する。
　ポート１１０と、管理Ｉ／Ｆ１２０と、ＣＰＵ１３０と、ＣＭ１４０、及び記憶ドライブ１６０は、内部ネットワーク１５０を介して接続されている。
　ポート１１０は、ホスト１０とのインタフェースの一例である。ポート１１０は、Ｎｏｄｅ１００を、ネットワーク１５０等を介して、他のＮｏｄｅ１００等の種々の装置と接続する。
　管理Ｉ／Ｆ１１２は、Ｎｏｄｅ１００を、管理サーバ２０と接続するためのインタフェースである。ポート１１０と、管理Ｉ／Ｆ１２０は、同一のものであっても良い。
　ＣＰＵ１３０は制御部であり、キャッシュメモリ１４０の制御プログラム格納領域１４２に格納されたプログラムを実行して各種処理を実行する。ＣＰＵ１３０は、各種コマンド（例えばＳＣＳＩにおけるＲＥＡＤコマンドやＷＲＩＴＥコマンドなど）を記憶ドライブ１６０に送信する。
　キャッシュメモリ１４０は、ホスト１０から記憶ドライブ１６０に書き込むデータ（ライトデータ）や、記憶ドライブ１６０から読み出したデータ（リードデータ）を一時的に格納する。
　また、キャッシュメモリ１４０内には、各種プログラムを格納する制御プログラム格納領域１４２と、各種情報を格納する制御情報格納領域１４１が設定される。なお、これらの情報は、キャッシュメモリ１４０以外の専用メモリ上に格納されていてもよく、また、記憶ドライブ１６０、キャッシュメモリ１４０内の複数の構成の記憶領域を用いて論理的な共有メモリを構成し、各種情報についてキャッシュ管理を行うようにしてもよい。
　記憶ドライブ１６０は、１以上の記憶媒体を含む。記憶媒体は、例えば、磁気ディスク、フラッシュメモリ、その他の不揮発性半導体メモリ（ＰＲＡＭ、ＲｅＲＡＭ等）である。
　Ｎｏｄｅ１００は、複数の記憶ドライブ１６０の記憶領域で構成される容量プール（以下、単にプールという）を管理する。Ｎｏｄｅ１００は、プール内の記憶領域を用いてＲＡＩＤグループを構成する。すなわち、Ｎｏｄｅ１００は、各Ｎｏｄｅ内の記憶ドライブ１６０を用いて、複数の論理的なＲＡＩＤグループを構成する。
　当該論理的なＲＡＩＤグループは、複数のサブ記憶領域列で構成されている。各サブ記憶領域列は、複数のサブ記憶領域で構成されている。複数のサブ記憶領域は、ＲＡＩＤグループを構成する複数の記憶ドライブ１６０に跨っており、複数の記憶ドライブ１６０にそれぞれ対応している。
　ここで、一つのサブ記憶領域を、「ストライプブロック」と呼び、サブ記憶領域列を、「ストライプ」と呼ぶ。複数のストライプ列によって、ＲＡＩＤグループの記憶領域が構成されている。
　ＲＡＩＤには、いくつかのレベル（以下、「ＲＡＩＤレベル」という）がある。例えば、ＲＡＩＤ５では、ＲＡＩＤ５に対応したホストコンピュータから指定された書き込み対象のデータは、所定サイズのデータ（以下、便宜上「データ単位」という）に分割される。各データ単位は、複数のデータ要素に分割される。複数のデータ要素は、同一のストライプ内の複数のストライプブロックにそれぞれ書き込まれる。
　ＲＡＩＤ５では、記憶ドライブ１６０、またはＮｏｄｅ１００に障害が発生したことにより、対応する記憶ドライブ１６０から読み出せなくなったデータ要素をリビルドするために、各データ単位に対して、"パリティ"と呼ばれる冗長な情報（以下、「冗長コード」）が生成される。
　冗長コードも、複数のデータ要素と同一のストライプ内のストライプブロックに書き込まれる。本実施例１では、ストライプブロックのうち、ユーザデータが格納されるものを「データブロック」と呼び、パリティデータが格納されるものを「パリティブロック」と呼ぶ。
　例えば、ＲＡＩＤグループを構成する記憶ドライブ１６０（すなわちＮｏｄｅ１００）の数が４である場合、そのうちの３個の記憶ドライブ１６０に対応する３個のデータブロックに、データ単位を構成する３個のデータ要素が書き込まれ、残りの一つの記憶ドライブ１６０に対応するパリティブロックに、冗長コードが書き込まれる。以下、データ要素と冗長コードとを区別しない場合には、両者をそれぞれストライプブロックということもある。
　ＲＡＩＤ６では、各データ単位に対して、２種類の冗長コード（Ｐパリティ、Ｑパリティという）が生成されて、それぞれの冗長コードが同一のストライプ内の異なるパリティブロックに書き込まれる。これにより、データ単位を構成する複数のデータ要素のうちの２個のデータ要素を読み出すことができない場合に、２種類の冗長コードから、これら２個のデータ要素を復元することができる。
　上記に説明した以外にもＲＡＩＤレベルは存在する（例えばＲＡＩＤ１～４）。データの冗長化技術として、３重ミラー（Ｔｒｉｐｌｉｃａｔｉｏｎ）や、パリティを３個用いたトリプルパリティ技術等も知られている。冗長コードの生成技術についても、ガロア演算を用いたＲｅｅｄ－ｓｏｌｏｍｏｎ符号や、ＥＶＥＮ－ＯＤＤ等さまざまな技術が存在する。以下においては、主にＲＡＩＤ５について説明するが、冗長化技術を上述した方法に置き換え可能である。
　Ｎｏｄｅ１００は、記憶ドライブ１６０のうちいずれかの記憶ドライブ１６０、あるいはＮｏｄｅ１００のうちいずれかのＮｏｄｅ１００が故障した場合に、故障した記憶ドライブ１６０に格納されているデータ要素を復元する。
　すなわち、ノード１００内の記憶ドライブ１６０でＲＡＩＤグループを構成し、さらに、ノード１００間でＲＡＩＤグループを構成するようにしても良い。
　ＣＰＵ１３０は、故障した記憶ドライブ１６０に格納されていたデータ要素を復元するために必要なストライプブロック（例えば、他のデータブロック及びパリティブロック）を、ポート１１０を介して、当該データを格納している他の複数のＮｏｄｅ内の記憶ドライブ１６０から取得する。ＣＰＵ１３０は、取得したストライプブロックをキャッシュメモリ１４０に格納する。その後、キャッシュメモリ１４０のストライプブロックに基づいてストライプブロックまたはパリティブロックを復元し、当該ストライプブロックを所定の記憶ドライブ１６０に格納する。
　例えば、ＲＡＩＤ５で構成されたＲＡＩＤグループのストライプブロックに対して、ＣＰＵ１３０は、ストライプを構成する複数のデータブロックの排他的論理和（ＸＯＲ）を演算することによってＰパリティを生成する。ＲＡＩＤ６で構成されたＲＡＩＤグループのデータブロックに対して、ＣＰＵ１３０は、更に、ストライプを構成する複数のデータブロックに所定の係数を掛けた後、それぞれのデータブロックの排他的論理和を演算することによって、Ｑパリティを生成する。
　以下、ＣＰＵ１３０の処理をＮｏｄｅ１００の処理として説明することがある。
　図２は、キャッシュメモリ１４０内の制御情報格納領域１４１を示すブロック図である。
　制御情報格納領域１４１は、ストライプ管理テーブル１００１と、Ｎｏｄｅ管理テーブル１００２と、ドライブ管理テーブル１００３と、Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブル１００４と、Ｐｏｏｌ管理テーブル１００５と、ＶＶＯＬ管理テーブル１００６と、パリティＮｏｄｅテーブル１００７と、更新中ストライプ管理テーブル１００９と、未割当ブロック管理テーブル１００８と、コピーポインタ１０１０とを格納する。各情報については後述する。
　図３は、キャッシュメモリ１４０内の制御プログラム格納領域１４２を示すブロック図である。
　制御プログラム格納領域１４２は、Ｎｏｄｅ増設処理プログラム１１０１と、ストライプ更新処理プログラム１１０２と、リビルド処理プログラム１１０３と、Ｉ／Ｏ処理プログラム１１０４とを格納する。なお、Ｉ／Ｏ処理プログラム１１０４以外の各プログラムの処理については後述する。Ｉ／Ｏ処理プログラム１１０４は、アクセス要求を受け付けて記憶ドライブ１６０に読み書きを実行するプログラムで、周知または公知の技術を適用すればよい。
　ＣＰＵ１３０は、各プログラムを実行することによって、所定の機能を提供する機能部として稼働する。例えば、ＣＰＵ１３０は、Ｎｏｄｅ増設処理プログラム１１０１に従って処理することでＮｏｄｅ増設部として機能する。他のプログラムについても同様である。さらに、ＣＰＵ１３０は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
　ノード１００の各機能を実現するプログラム、テーブル等の情報は、記憶ドライブ１６０や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。
　図４は、記憶ドライブ１６０のデータ構成の一例を示すブロック図である。
　記憶ドライブ１６０は、Ｎｏｄｅ１００等の装置との間で、ＳＣＳＩコマンド処理の最小単位（例えば、５１２Ｂｙｔｅ）であるサブブロック２００を単位として、データの受け渡しを行う。
　スロット２０１は、キャッシュメモリ１４０上でのデータをキャッシュする際の管理単位であり、例えば、２５６ＫＢである。スロット２０１は、連続する複数のサブブロック２００の集合で構成される。ストライプブロック２０２は、複数（例えば、２個）のスロット２０１を格納する。
　図５Ａ、図５Ｂは、本実施例１に係るＲＡＩＤグループ構成の概略図である。
　図５Ａは各Ｎｏｄｅ１００－１～１００－４内の記憶ドライブ１６０、及びストライプ構成の詳細を示す図である。図５ＢはＮｏｄｅ１００－１～１００－４内のストライプブロック２０２の配置を示す図である。図示では、ｎ＝４として、４つのＮｏｄｅ１００でＲＡＩＤ５のグループを構成する例を示す。
　各Ｎｏｄｅ１００には、複数の記憶ドライブ１６０が含まれており、記憶ドライブ１６０は、一定サイズのストライプブロック２０２に分割されている。
　計算機システム１では、管理サーバ２０が、各Ｎｏｄｅ１００－１～１００－４内の所定のストライプブロック２０２を選択し、Ｎｏｄｅ１００－１～１００－４間で論理的なＲＡＩＤグループ（ストライプ２０３）を構成する。なお、図５Ａにおいて、Ｎｏｄｅ１００－３については図示を省略した。
　図５Ｂでは、例えば、ストライプ２０３－０は、「Ａ０」、「Ｂ０」、「Ｃ０」、「Ｐ０」のストライプブロック２０２で構成される。「Ａ０」、「Ｂ０」、「Ｃ０」、「Ｐ０」は、それぞれ各Ｎｏｄｅ１００－１～１００－４のドライブ＃０の先頭のストライプブロック２０２から構成されている。
　図５Ｂでは、各ノード１００－１～１００－４で、ストライプ２０３－０～２０３－９を構成した例を示す。
　以下では、図中「Ａ０」、「Ｂ０」、「Ｃ０」のように、ユーザデータが格納されるストライプブロック２０２をデータブロックと呼び、図中「Ｐ０」のように、パリティデータが格納されるストライプブロック２０２をパリティブロックと呼ぶ。
　ストライプ２０３を構成するストライプブロック２０２のうち、２以上のストライプブロック２０２が同一のＮｏｄｅ１００に存在した場合、Ｎｏｄｅ障害発生時に、ストライプ２０３の冗長度が一度に２以上低下してしまい、データロストが発生する可能性がある。そのため、全てのストライプ２０３は、異なるＮｏｄｅ１００内のストライプブロック２０２から構成される必要がある。
　また、ストライプ２０３を構成するストライプブロック２０２の数は、必ずしもＮｏｄｅ１００の数と同じである必要はなく、例えばＮｏｄｅ１００の数が１０で構成されている計算機システム１で、３Ｄ＋１Ｐのストライプを構成する場合は、１０台のＮｏｄｅ１００のうち４つのＮｏｄｅ１００を選択し、各Ｎｏｄｅ１００内で所定のストライプブロック２０２でストライプ２０３を構成すればよい。
　なお、以降の説明では、Ｎｏｄｅ１００内の記憶ドライブ１６０の構成を説明する必要がある場合のみ図５Ａを用いて説明し、それ以外は、説明の簡略化のため図５Ｂを用いて説明する。
　図６は、本実施例１に係る計算機システムの論理構成の一例を示す図である。
　計算機システム１は、該複数のＮｏｄｅ１００内の記憶ドライブ１６０の領域を束ねて、１以上の容量プール２１０（以下単にプールとも呼ぶ）を構成する。プール２１０は、記憶ドライブ１６０の全領域から、パリティブロックが格納されている領域を除いた、データブロックで構成される。
　前述したように、各Ｎｏｄｅ１００内の記憶ドライブ１６０は、例えば、フラッシュメモリドライブ、ＳＡＳドライブ、ＳＡＴＡドライブなど、性能や特性が異なる複数種類の記憶デバイスで構成される場合がある。プール２１０内に性能や特性の異なる記憶ドライブ１６０が混在した場合、性能の低い記憶ドライブ１６０がボトルネックとなってしまう。
　そのため、プール２１０は、単一の性能や特性を有する記憶ドライブ１６０で構成されることが望ましい。例えば、各Ｎｏｄｅ１００内に性能や特性の異なる記憶ドライブ１６０が存在する場合は、その性能や特性に応じて複数のプール２１０を構成すればよい。或いは、プール２１０内を、論理的なパーティション（またはＴｉｅｒ）で区切り、後述するページ２１３を、単一のＴｉｅｒ内に存在するデータブロックで構成するようにしてもよい。
　各Ｎｏｄｅ１００は、内部の物理的な記憶領域を所定のサイズに切り分けて、Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１（ＰｏｏｌＶｏｌとも呼ぶ）を生成する。Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１は、記憶ドライブ１６０の性能を最大限に発揮するため、単一の性能や特性を有する記憶ドライブ１６０で構成されることが望ましい。
　各Ｎｏｄｅ１００は、Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１を適切なプール２１０に割り当てることにより、プール２１０を構成する。言い換えれば、プール２１０は、複数のＰｏｏｌ　Ｖｏｌｕｍｅ２１１から構成されていると考えることもできる。同一のＮｏｄｅ１００内のＰｏｏｌ　Ｖｏｌｕｍｅ２１１は、必ずしも同一のプール２１０に割り当てられる必要はなく、複数のプール２１０に分けて割り当てても良い。図６の例では、Ｎｏｄｅ＃３の４つのＰｏｏｌ　Ｖｏｌｕｍｅ２１１は、プール＃０とプール＃１にそれぞれ２つずつ割り当てられている。
　プール２１０内には複数の仮想ボリューム（ＶＶＯＬ：Ｖｉｒｔｕａｌ　ＶＯＬｕｍｅ）２１２が生成される。ＶＶＯＬ２１２は、仮想的な記憶デバイスであり、ホスト１０から参照されることができる。計算機システム１の管理者からの指示に応じて、管理サーバ２０は、Ｎｏｄｅ１００の管理Ｉ／Ｆ１２０を介して、所定のサイズのＶＶＯＬ２１２を生成させる。
　生成させるサイズは、実際の記憶ドライブ１６０の総使用可能容量に依存しない。各Ｎｏｄｅ１００は、ホスト１０からのＩ／Ｏ要求（ホストＩ／Ｏ）により示されたＶＶＯＬ２１２内の記憶領域（ＶＶＯＬページ２１３）に対して、プール２１０内の記憶領域（ＰｏｏｌＶｏｌページ２１４）をＶＶＯＬ２１２へ動的に割り当てる。ＶＶＯＬ２１２の記憶領域は、ＶＶＯＬページ２１３で管理することができる。
　ＶＶＯＬページ２１３を異なるＰｏｏｌ　Ｖｏｌｕｍｅ２１１に所属するストライプブロック２０２で構成した場合、同一のＶＶＯＬページ２１３に対するＩ／Ｏが、複数のＮｏｄｅ１００に分散されてしまい、Ｎｏｄｅ１００の間転送によるレイテンシの増加が問題となる。このため、ＶＶＯＬページ２１３は本実施例１のように同一のＰｏｏｌ　Ｖｏｌｕｍｅ２１１内のストライプブロック２０２から構成されることが望ましい。
　ＰｏｏｌＶｏｌページ２１４は、容量プール２１０内の１以上のデータブロックから構成される。ＰｏｏｌＶｏｌページ２１４を構成するデータブロック数は、計算機システム内で一意に定められるが、ＲＡＩＤグループの構成には依存しないため、ＲＡＩＤグループの構成を変更した場合も、ＰｏｏｌＶｏｌページ２１４とデータブロック間の割当を変更する必要はない。
　プール２１０内に複数のＴｉｅｒが存在する場合、Ｎｏｄｅ１００は、ＶＶＯＬページ２１３毎にアクセス頻度を記録し、アクセス頻度の高いＶＶＯＬページ２１３に対して、例えばフラッシュメモリドライブのような高性能な記憶ドライブ１６０内で構成されるＰｏｏｌＶｏｌページ２１４を割り当てるようにしてもよい。Ｎｏｄｅ１００は、継続的にＶＶＯＬページ２１３の負荷を監視して、周期的にＶＶＯＬページ２１３の割り当てを変更してもよい。
　図７は、ストライプ管理テーブル１００１の一例を示す図である。ストライプ管理テーブル１００１は、計算機システム１で共通の情報であり、ストライプ２０３を構成する、各Ｎｏｄｅ１００内のストライプブロックの組み合わせを示す情報である。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　ストライプ管理テーブル１００１は、ストライプ２０３の識別子を格納するＳｔｒｉｐｅ＃２０００と、計算機システム１を構成する各Ｎｏｄｅ１００の識別子毎のストライプ２０３の格納位置を保持するＮｏｄｅ＃２００１と、ストライプ２０３に含まれるパリティブロックの格納位置のＮｏｄｅ１００の識別子を格納するＰａｒｉｔｙ　Ｎｏｄｅ＃２００２と、次回に処理するフラグを格納するＮＥＸＴ２００３のフィールドを一つのエントリに含む。図示では、Ｎｏｄｅ１００が「＃０」～「＃４」の５つで構成される例を示す。
　Ｓｔｒｉｐｅ＃２０００はストライプ２０３の識別子であり、各Ｎｏｄｅ＃２００１は、各Ｓｔｒｉｐｅ＃２０００に対応するＮｏｄｅ内のストライプブロック位置（ＬＢＡ＃：Ｌｏｇｉｃａｌ　Ｂｌｏｃｋ　Ａｄｄｒｅｓｓ）を示し、Ｐａｒｉｔｙ　Ｎｏｄｅ＃２００２はパリティブロックの格納されているＮｏｄｅ１００を示す。
　本テーブルにより、Ｎｏｄｅ１００は、各ストライプ２０３を構成するＮｏｄｅ＃２００１、及びＮｏｄｅ１００内のストライプブロック位置と、パリティブロックが格納されているＮｏｄｅ１００を参照することができる。
　例えば、図７の例では、Ｓｔｒｉｐｅ＃２０００＝「０」のストライプ２０３は、（Ｎｏｄｅ＃、ＬＢＡ＃）＝（０、０ｘ００）、（１、０ｘ００）、（２、０ｘ００）、（３、０ｘ０１）、（４、０ｘ００）の４つストライプブロック２０２から構成されており、Ｎｏｄｅ＃４のストライプブロック２０２がパリティブロックである。
　図７は、ストライプあたりのパリティブロック数が１、すなわちＲＡＩＤ５の場合のストライプ管理テーブルの例であるが、ストライプあたりのパリティブロック数が２、すなわちＲＡＩＤ６の場合は、Ｐａｒｉｔｙ　Ｎｏｄｅ＃２００２に、Ｑパリティブロック分のフィールドが追加される。
　また、構成によっては、ストライプ２０３が、計算機システム１内の全Ｎｏｄｅ１００に跨っていない場合も考えられる。この場合は、各Ｓｔｒｉｐｅ＃２０００を構成するストライプブロック２０２が格納されているＮｏｄｅ＃２００１にのみＮｏｄｅ１００内のストライプブロック位置（ＬＢＡ＃）が格納され、それ以外のＮｏｄｅ＃２００１には所定の無効値が格納される。
　ＮＥＸＴ２００３には、次回の処理でストライプ更新処理の対象となるフラグが格納され、次回に処理するストライプには「１」が設定される。
　なお、後述するように、Ｎｏｄｅ１００を増設する際のストライプ２０３の再構成では、ストライプ管理テーブル１００１の更新（ストライプ構成の更新）が実施される。ストライプ構成の更新時には、当該ストライプ管理テーブル１００１に加え、更新中ストライプ管理テーブル１００９を用いて処理をする。更新中ストライプ管理テーブル１００９のフィールドは、図７のストライプ管理テーブル１００１と同様である。更新中ストライプ管理テーブル１００９は、ストライプ構成の更新処理中に、更新後のストライプ構成を示す情報が適宜格納されていく。
　また、ストライプ構成の更新処理は、後述するように、ＲＡＩＤグループに新たなＮｏｄｅ１００を追加する際に実行される処理で、パリティブロックを格納するＮｏｄｅ１００を分散させる処理である。
　図８は、Ｎｏｄｅ管理テーブル１００２の一例を示す図である。Ｎｏｄｅ管理テーブル１００２は、計算機システム１で共通の情報であり、各Ｎｏｄｅ１００の状態を管理する情報である。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　Ｎｏｄｅ管理テーブル１００２は、Ｎｏｄｅ１００の識別子を格納するＮｏｄｅ＃２０１０と、各Ｎｏｄｅ１００の状態を格納するＳｔａｔｕｓ２０１１のフィールドを含む。Ｎｏｄｅ＃２０１０はＮｏｄｅの識別子であり、Ｓｔａｔｕｓ２０１１には、正常（Ｎｏｒｍａｌ）、または障害（Ｆａｉｌｅｄ）など、対応するＮｏｄｅ１００の状態が格納される。
　図９は、ドライブ管理テーブル１００３の一例を示す図である。ドライブ管理テーブル１００３は、Ｎｏｄｅ１００ごとに管理される情報であり、Ｎｏｄｅ１００内のドライブ情報を管理する情報である。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　ドライブ管理テーブル１００３は、Ｐｏｏｌ　Ｖｏｌｕｍｅ＃２０２０と、Ｔｙｐｅ２０２１と、Ｄｒｉｖｅ＃２０２２と、Ｓｉｚｅ２０２３と、Ｓｔａｔｕｓ２０２４のフィールドを一つのエントリに含む。
　Ｐｏｏｌ　Ｖｏｌｕｍｅ＃２０２０にはＰｏｏｌ　Ｖｏｌｕｍｅ２１１の識別子が格納される。Ｔｙｐｅ２０２１にはＳＳＤや、ＮＬ（Ｎｅａｒ　Ｌｉｎｅ）－ＳＡＳなどの記憶ドライブ１６０の種別が格納される。
　Ｄｒｉｖｅ＃２０２２には、各Ｎｏｄｅ１００内で一意に定まる記憶ドライブ１６０の識別子が格納される。Ｓｉｚｅ２０２３には各記憶ドライブ１６０の容量（例えばサブブロック２００単位）が格納される。Ｓｔａｔｕｓ２０２４には各記憶ドライブ１６０の状態が格納される。
　ドライブ管理テーブル１００３により、Ｎｏｄｅ１００は、Ｎｏｄｅ１００内の記憶ドライブ１６０の数量や、種別や、容量および、状態を取得することができる。
　また、Ｓｔａｔｕｓ２０２４には、「Ｎｏｒｍａｌ（正常）」、「Ｆａｉｌｅｄ（障害）」などのドライブ状態が格納されるが、これ以外にも、予防保守を目的として、エラー回数が閾値を超過した記憶ドライブ１６０に対して、「Ｗａｒｎｉｎｇ（警告）」などの状態を格納しても良い。
　図１０は、Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブル１００４の一例を示す図である。
　Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブル１００４は、計算機システム１で共通の情報であり、各Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１の容量、及びＰｏｏｌ　Ｖｏｌｕｍｅ２１１の存在するＮｏｄｅ１００を計算機システム１が管理するために用いられる。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブル１００４は、Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１の識別子を格納するＰｏｏｌ　Ｖｏｌｕｍｅ＃２０３０と、Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１の種別を格納するＴｙｐｅ２０３１と、Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１の容量を格納するＳｉｚｅ２０３２と、Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１が割り当てられたＮｏｄｅ１００の識別子を格納するＮｏｄｅ＃２０３３のフィールドを一つのエントリに含む。
　Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブル１００４を参照することにより、計算機システム１は、各Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１の容量と、種別、及びそのＮｏｄｅ１００の識別子を取得することができ、Ｐｏｏｌ２１０にどのＰｏｏｌ　Ｖｏｌｕｍｅ２１１を追加するかを決定する場合などに使用される。
　図１１は、Ｐｏｏｌ管理テーブル１００４の一例を示す図である。
　Ｐｏｏｌ管理テーブル１００５は、計算機システム１で共通の情報であり、各Ｐｏｏｌ２１０を計算機システム１が管理するために用いられる。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　Ｐｏｏｌ管理テーブル１００５は、Ｐｏｏｌ＃２０４０と、Ｓｉｚｅ２０４１と、Ｕｎｕｓｅｄ２０４２と、Ｐｏｏｌ　Ｖｏｌｕｍｅ＃２０４３のフィールドを一つのエントリに含む。
　Ｐｏｏｌ＃２０４０には、プール２１０の識別子が格納される。Ｓｉｚｅ２０４１にはプール２１０全体の容量（ブロック数）が格納される。Ｕｎｕｓｅｄ２０４２には、Ｓｉｚｅ２０４１のうち、使用可能な容量（ブロック数）が格納される。また、Ｐｏｏｌ　Ｖｏｌｕｍｅ＃２０４３には、当該Ｐｏｏｌ２１０に割り当てられている全Ｐｏｏｌ　Ｖｏｌｕｍｅ２１１の識別子が格納される。Ｐｏｏｌ管理テーブル１００４を参照することにより、計算機システム１は、各Ｐｏｏｌ２１０の使用状況を取得することができる。
　図１２は、ＶＶＯＬ管理テーブル１００６の一例を示す図である。ＶＶＯＬ管理テーブル１００６は、計算機システム１で共通の情報であり、ＶＶＯＬページ２１３と、ＰｏｏｌＶｏｌページ２１４との対応関係を示す情報である。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　ＶＶＯＬ管理テーブル１００６は、ＶＶＯＬ＃２０５０と、ＶＶＯＬページ＃２０５２と、ＰｏｏｌＶｏｌ＃２０５３と、ＰｏｏｌＶｏｌページ＃２０５４のフィールドを一つのエントリに含む。
　ＶＶＯＬ＃２０５０には、ＶＶＯＬ２１２の識別子が格納される。Ｓｉｚｅ２０５１には、当該ＶＶＯＬ２１２の容量（ブロック数）が格納される。ＶＶＯＬページ＃２０５２には、当該ＶＶＯＬに含まれるＶＶＯＬページ２１３の識別子が格納される。
　ＰｏｏｌＶｏｌ＃２０５２には、当該ＶＶＯＬ２１２に割り当てられたＰｏｏｌＶｏｌｕｍｅ２１１の識別子が格納される。Ｐｏｏｌ　Ｖｏｌページ＃２０５４には、当該ＶＶＯＬページ２１３に割り当てられたＰｏｏｌＶｏｌページ２１４の識別子が格納される。
　未使用のＶＶＯＬページ＃２０５２に対応するＰｏｏｌＶｏｌ＃２０５３及びＰｏｏｌＶｏｌページ＃２０５４には、「未割当」に相当する値が格納される。ＶＶＯＬ管理テーブル１００６を参照することにより、計算機システム１は、ＶＶＯＬ２１２の使用状況や、割当先の情報を取得することができる。
　図１３Ａは、パリティＮｏｄｅテーブル１００７の一例を示す図である。
　パリティＮｏｄｅテーブル１００７は、計算機システム１で共通の情報であり、後述するストライプ構成の更新処理にて、パリティブロックが格納されるＮｏｄｅ１００を分散するために使用される情報である。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　パリティＮｏｄｅテーブル１００７は、サイクル内インデックス（図中Ｉｎ－Ｃｙｃｌｅ　Ｉｎｄｅｘ）＃２０６０と、Ｐａｒｉｔｙ　Ｎｏｄｅ＃２０６１のフィールドを一つのエントリに含む。
　後述するストライプ構成の更新処理は、Ｎ＋２個のストライプ２０３ごとに周期的な処理であり、サイクル内インデックス＃２０６０には、０からＮ＋１まで周期内のオフセット値が周期内のインデックスとして格納される。なお、Ｎは、新たなＮｏｄｅ１００を追加する前のデータブロックを含むＮｏｄｅ１００の数を示す。換言すれば、Ｎは、Ｎｏｄｅ１００を拡張する前のデータブロック数となる。
　Ｐａｒｉｔｙ　Ｎｏｄｅ＃２０６１には、当該オフセット値に対応するストライプ２０３において、パリティブロックが格納されているＮｏｄｅ１００を表す。
　本実施例１では、図１４で示すように、４つのＮｏｄｅ１００で３Ｄ＋１ＰのＲＡＩＤグループに、１つのＮｏｄｅ１００を追加する例を示す。
　４つのＮｏｄｅ１００に、１つのＮｏｄｅ１００を追加する場合、５つのＮｏｄｅ１００にパリティブロックを分散させる処理を後述するように実施する。本実施例１の場合、ストライプ構成の更新処理を５回繰り返すことで、新たに追加するＮｏｄｅ１００にもパリティブロックを分散させて、同一のＮｏｄｅ１００に重複することなく、各Ｎｏｄｅ１００にパリティブロックを分散させる。すなわち、本実施例１の場合、５回の処理が１つの周期となる。
　パリティＮｏｄｅテーブル１００７の使用については、後述のストライプ構成の更新処理を説明する際に詳細を述べる。
　図１３Ｂは、未割当ブロック管理テーブルの一例を示す図である。未割当ブロック管理テーブル１００８は、計算機システム１で共通の情報であり、後述するストライプ構成の更新処理にて、更新後のパリティブロックを格納する領域を取得するために使用される情報である。なお、計算機システム１で共通の情報は、例えば、他のＮｏｄｅ１００及び管理サーバ２０から参照可能である。
　未割当ブロック管理テーブル１００８は、Ｎｏｄｅ＃２０７０と、ＬＢＡ＃２０７１のフィールドを一つのエントリに含む。Ｎｏｄｅ＃２０７０にはＮｏｄｅ１００の識別子が格納される。ＬＢＡ＃２０７１には未割当となったブロックのアドレスが格納される。
　後述するストライプ構成の更新処理では、更新前のストライプ構成で一時的に未割当となるブロックが存在する。当該ブロックを識別するための情報が、Ｎｏｄｅ＃２０７０と、ＬＢＡ＃２０７１である。
　未割当ブロック管理テーブル１００８の使用については、後述のストライプ構成の更新処理を説明する際に詳細を述べる。
　図１４は、本実施例１に係る、Ｎｏｄｅ１００の増設時に実行されるストライプ構成の更新処理の概要を示す図である。本実施例１では、Ｎｏｄｅ１００－１～１００－４（＃０～
＃３）で構成された３Ｄ＋１ＰのＲＡＩＤグループに、新たなＮｏｄｅ１００－５（＃４）を追加する例を示す。なお、以下の説明では、Ｎｏｄｅ１００－１～１００－５をＮｏｄｅ＃０～Ｎｏｄｅ＃４として説明する。また、新たに追加するＮｏｄｅ＃４を増設Ｎｏｄｅとする。
　（１）は増設直後のＮｏｄｅ１００の構成を示す。具体的には、Ｎｏｄｅ＃０～＃３の４つのＮｏｄｅで３Ｄ＋１ＰのＲＡＩＤグループを構成していた状態から、１Ｎｏｄｅ（Ｎｏｄｅ＃４）を追加した直後の状態である。図中で、"Ａｘ"、"Ｂｘ"などはデータブロックを示し、"Ｐｘ"はパリティブロックを示す。ただし、ｘ＝０～ｎ。
　また、図中太線で接続されたストライプブロック２０２は、１つのストライプ２０３を構成するストライプブロック２０２であることを示す。図１４の例では、Ａ０、Ｂ０、Ｃ０、Ｐ０がストライプ２０３－０を構成している。
　なお前提として、増設したＮｏｄｅ（Ｎｏｄｅ＃４）のストライプブロック２０２には、すべてゼロ（パリティの値に影響しない所定のデータ）が格納されているか、或いは内部的にゼロが格納されているとみなして処理を行う。
　以下では便宜上、Ｎｏｄｅ＃０のストライプブロック＃ｘを含むストライプ２０３のストライプ＃（番号）を、ストライプ＃ｘと定義する。ただし、ｘ＝０～ｎ。すなわち、Ａ０を含むストライプをストライプ＃０とし、Ａ１を含むストライプ２０３をストライプ＃１とする。
　（２）はストライプ＃０を再構成する例を示す。計算機システム１は、まずストライプ＃０のパリティブロック（Ｐ０）と、当該パリティブロックを含むＮｏｄｅ（Ｎｏｄｅ＃３）のうち所定のデータブロック（Ｄ１）から、中間パリティ（Ｐｉ）を演算して生成する。
　計算機システム１は、当該中間パリティ（Ｐｉ）を、増設Ｎｏｄｅ（Ｎｏｄｅ＃４）内の所定のブロックに新パリティ（Ｐ'０）として格納する。本実施例１において、中間パリティ（Ｐｉ）はＰ０　ＸＯＲ　Ｄ１で算出される。"ＸＯＲ"は、排他的論理和演算を行う演算子である。以下では、簡略化のためＸＯＲ演算子を図中"＋"の記号を用いて記述する。
　上記処理により、ストライプ＃０（２０３－０'）を構成するストライプブロック２０２は、Ａ０、Ｂ０、Ｃ０、Ｄ１、Ｐ'０に更新される。なお、Ｐ０＝Ａ０＋Ｂ０＋Ｃ０、及びＰ'０＝Ｐｉ＝Ｐ０＋Ｄ１であるから、Ｐ'０＝Ａ０＋Ｂ０＋Ｃ０＋Ｄ１となり、Ｐ'０は、ストライプ＃０のパリティとしての要件を満たしている。
　また、上記ストライプ＃０の再構成によって、ストライプ＃０から除外（無効化）されたパリティブロック（Ｐ０）は、未割当ブロック管理テーブル１００８に当該ブロックの情報（Ｎｏｄｅ１００の識別子とブロックの位置）が格納される。ストライプ＃０から除外されたパリティブロック（Ｐ０）は、未割り当てのストライプブロック２０２として管理される。
　また、上記処理では、中間パリティＰｉのみを他のＮｏｄｅ＃４に転送すればよいので、Ｎｏｄｅ間のデータの移動を低減して処理の遅延を抑制することができる。
　また、中間パリティＰｉは、ストライプ＃０に所属していたパリティブロック（Ｐ０）と、当該パリティブロックと同一のＮｏｄｅ＃３で、ストライプ＃０に新たに追加されたデータブロック（Ｄ１）とで排他的論理和を演算する。したがって、同一のＮｏｄｅ内のストライプブロック２０２からパリティの演算を行えば良いので、Ｎｏｄｅ間のアクセスを不要にして、演算処理を高速化できる。
　（３）はストライプ＃１（２０３－１'）を再構成する例を示す。再構成処理を行うストライプ＃１の順序は、前回のストライプの処理における中間パリティの生成時に、どのストライプ＃のデータブロックを用いたかによって一意に決定される。この決定の詳細は後述する。
　計算機システム１は、まずストライプ＃１のパリティブロック（Ｐ１）と、当該パリティブロックを含むＮｏｄｅ（Ｎｏｄｅ＃２）のうち所定のデータブロック（Ｃ２）から、排他的論理和によって中間パリティ（Ｐｉ）を生成する。
　次に、計算機システム１は、生成した当該中間パリティ（Ｐｉ）を、前回のストライプの処理（インデックス＃＝０）において、無効化されたパリティブロック（Ｐ０）が格納されているＮｏｄｅ（Ｎｏｄｅ＃３）に転送する。なお、計算機システム１は、図１３Ｂに示した未割当ブロック管理テーブル１００８を参照することで、無効化されたパリティブロック（Ｐ０）の位置（Ｎｏｄｅ、ＬＢＡ）を取得することができる。
　次に、中間パリティ（Ｐｉ）を受信したＮｏｄｅ＃３では、ストライプ＃１に対応するデータブロック（Ｄ１）と、当該中間パリティ（Ｐｉ）の排他的論理和によって、新たなパリティ（Ｐ'１）を生成し、無効化されたパリティブロック（Ｐ０）の位置に格納する。
　本実施例１において、新たなパリティ（Ｐ'１）は、Ｐｉ＋Ｄ１で算出される。その後、増設Ｎｏｄｅ＃４内の所定のデータブロック（Ｅ１）を更新後のストライプ＃１のデータブロックとして定義する。なお、増設Ｎｏｄｅ＃４のデータブロックの値は全て０であるので、新たなパリティ（Ｐ'１）の値は変わらない。
　上記処理により、ストライプ＃１を構成するストライプブロック２０２は、Ａ１、Ｂ１、Ｃ２、Ｐ'１、Ｅ１に更新される。なお、Ｐ１＝Ａ１＋Ｂ１＋Ｄ１、Ｐｉ＝Ｐ１＋Ｃ２、及びＰ'１＝Ｐｉ＋Ｄ１であるから、Ｐ'１＝Ａ１＋Ｂ１＋Ｃ２となり、かつＥ１＝０であるから、Ｐ'１＝Ａ１＋Ｂ１＋Ｃ２＋Ｅ１となり、Ｐ'１は、ストライプ＃１のパリティとしての要件を満たしている。
　計算機システム１は、以下同様の処理を繰り返して、図１４の（４）のような増設後のストライプ構成に更新する。本処理は周期的な処理であり、ストライプ＃５ｋ～＃５ｋ＋４（ｋは０以上の整数）の更新処理、即ちストライプブロック２０２の組み合わせパターンは、上記ストライプ＃０～＃４と同様のものとなる。
　なお、ストライプ更新処理は、周期内の位置によって処理の種類が異なる。このため、図１４の（４）には、後述するストライプ更新処理の種類を「処理の種類」として表示した。なお、周期の終端及び周期終端の１つ前のストライプ更新処理に関しては、上記記述と一部異なる部分があるが、詳細については後述する。
　以下、計算機システム１及び、各Ｎｏｄｅ１００の処理の詳細について説明する。
　図１５は、Ｎｏｄｅ増設処理の一例を示すフローチャートである。
　Ｎｏｄｅ増設処理プログラム１１０１は、計算機システム１にＮｏｄｅ１００を増設する場合のストライプ構成の更新処理を行う。
　管理者は、計算機システム１に対して増設用のＮｏｄｅ１００を追加した後、Ｎｏｄｅ増設（またはストライプ２０３の拡張）の指示を管理サーバ２０へ入力する。管理サーバ２０は、増設するＲＡＩＤグループ（またはＮｏｄｅ１００）と増設Ｎｏｄｅを受け付けて、処理対象のＮｏｄｅ１００に増設指令を送信する。
　本実施例１では、図１４及び図７で示すように、Ｎｏｄｅ＃０～＃３のＲＡＩＤグループ（３Ｄ＋１Ｐ）にＮｏｄｅ＃４を追加する例を示すが、これに限定されるものではない。例えば、計算機システム１内に複数のＲＡＩＤグループが設定されている場合には、ＲＡＩＤグループとＮｏｄｅ１００の対応関係を示すテーブル（図示省略）を管理サーバ２０が参照して、処理対象のＮｏｄｅ１００を特定すれば良い。
　各Ｎｏｄｅ１００は、管理サーバ２０からの増設指示を受信した契機で、Ｎｏｄｅ増設処理を実行する。また、Ｎｏｄｅ増設を検出した契機で、自動的に各Ｎｏｄｅ１００が当該Ｎｏｄｅ増設処理プログラム１１０１を実行しても良い。
　あるいは、処理対象のＮｏｄｅ１００のうちいずれかひとつが、マスターとなってＮｏｄｅ増設処理プログラム１１０１を実行し、他のＮｏｄｅ１００に通知するようにしても良い。あるいは、管理サーバ２０がＮｏｄｅ増設処理プログラム１１０１を実行して処理対象のＮｏｄｅ１００に通知しても良い。
　まず、Ｎｏｄｅ増設処理プログラム１１０１は、増設処理の対象となるＮｏｄｅ１００の中から、１つのＮｏｄｅ１００（増設用Ｎｏｄｅ１００（＃４））を増設対象Ｎｏｄｅとして選択する（ステップ３１０１）。
　例えば、Ｎｏｄｅ増設処理プログラム１１０１は、増設処理の対象Ｎｏｄｅのうち、Ｎｏｄｅ増設処理が未実施のＮｏｄｅのうち、計算機システム１内の物理的なＮｏｄｅ＃が若い順に、対象Ｎｏｄｅを選んでもよい。
　次に、Ｎｏｄｅ増設処理プログラム１１０１は、ストライプ構成の更新処理を実施する（ステップ３００２）。ストライプ構成の更新処理については後述する。
　次に、Ｎｏｄｅ増設処理プログラム１１０１は、計算機システム１に対して追加した全増設Ｎｏｄｅに対してＮｏｄｅ増設処理が完了しているかを判定する（ステップ３００３）。全増設Ｎｏｄｅに対してＮｏｄｅ増設処理が完了していない場合（ステップ３００３でＮｏ）、Ｎｏｄｅ増設処理プログラム１１０１は、ステップ３００１に戻り、次の対象Ｎｏｄｅに対して同様の処理を実施する。
　一方、全増設Ｎｏｄｅに対してＮｏｄｅ増設処理が完了している場合（ステップ３００３でＹｅｓ）は、Ｎｏｄｅ増設処理プログラム１１０１が処理を終了する。
　図１６は、ストライプ構成の更新処理の一例を示すフローチャートである。この処理は、図１５のステップ３００２の処理で、各Ｎｏｄｅ１００が増設Ｎｏｄｅ１００を受け付けて、ストライプ更新処理プログラム１１０２を実行する。
　ストライプ更新処理プログラム１１０２は、図１５のＮｏｄｅ増設処理のステップ３００２において、Ｎｏｄｅ１００を増設した後のストライプパターンを生成し、増設後のストライプパターンに対応するパリティブロックの生成を行う。これらストライプパターンの生成とパリティブロックの生成が、ストライプ構成の更新処理に含まれる。
　まず、ストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１を参照し、計算機システム１内のストライプ数（Ｓ）を算出する（ステップ３１０１）。
　次に、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をゼロに設定する（ステップ３１０２）。ストライプイテレータｉは、現在処理中のストライプ＃（番号）を意味し、０～Ｓ－１までの値が設定される。
　次に、ストライプ更新処理プログラム１１０２は、ストライプ数（Ｓ）とストライプイテレータ（ｉ）の差分Ｓ－ｉ、即ち未更新のストライプ数が、拡張前のデータブロック数（ｎ）＋パリティブロック数＋１以上か否かの判定を行う（ステップ３１０３）。なお、本実施例１ではＲＡＩＤ５のグループを採用するため、パリティブロック数は１である。このため、ストライプ更新処理の周期は、ｎ＋２となる。また、本実施例１では、図１４で示したように、拡張前のデータブロック数（ｎ）＝３の例を示す。
　未更新のストライプ数がｎ＋２以上の場合（ステップ３１０３でＹｅｓ）、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（周期）を実施する（ステップ３１０４）。ストライプ更新処理（周期）については後述する。なお、更新対象のストライプ２０３に含まれるＮｏｄｅ１００間では、ステップ３１０４の開始時等に、ストライプイテレータ（ｉ）の同期をとるようにしてもよい。
　ストライプ更新処理（周期）を実施した後、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をインクリメントし、再度ステップ３１０３の判定を実施する。
　一方、未更新のストライプ数がｎ＋２未満である場合（ステップ３１０３でＮｏ）、ストライプ更新処理プログラム１１０２は、未更新のストライプ２０３が存在するか、即ちストライプイテレータ（ｉ）がＳ未満であるかの判定を行う（ステップ３１０６）。
　ステップ３１０３の判定では、未更新のストライプ数（Ｓ－ｉ）が、ストライプ更新処理の周期（ｎ＋２）未満であるか否かについて判定が実施される。そして、未更新のストライプ数が周期未満の場合には、ステップ３１０６で、未更新のストライプ数が周期に満たない端数を含むか否かについて判定が実施される。
　未更新のストライプが存在する場合（ステップ３１０６でＹｅｓ）、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（端数）を実施する（ステップ３１０７）。ストライプ更新処理（端数）については後述する。
　ストライプ更新処理（端数）を実施した後、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をインクリメントし、再度ステップ３１０６の判定を実施する。
　未更新のストライプ２０３が存在しない場合（ステップ３１０６でＮｏ）、ストライプ更新処理プログラム１１０２は処理を終了し、図１５の処理に復帰する。
　上記処理によって、未更新のストライプ数（Ｓ－ｉ）が、ストライプ更新処理の周期（ｎ＋２）以上であればステップ３１０４のストライプ更新処理（周期）が実行され、未更新のストライプ数が周期未満になると、ステップ３１０７のストライプ更新処理（端数）に切り替えられる。
　図１７は、ストライプ更新処理（周期）の一例を示すフローチャートである。
　ストライプ更新処理（周期）は、ストライプ更新処理プログラム１１０２の一部として実施され、図１６に示したストライプ更新処理のステップ３１０４において、各ストライプ２０３のストライプパターンを生成する。当該ストライプパターンは、Ｎｏｄｅ１００間のパリティブロックの配置を平準化するため、周期的なパターンを生成する。
　まず、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）を参照し、ｉ　ｍｏｄ　（ｎ＋２）の値を算出する（ステップ３２０１）。ｎは、拡張前のストライプのデータブロック数を表す。なお、「ｍｏｄ」は、ｉをｎ＋２で除した余りを算出する関数を示す。
　算出結果が０であった場合、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（周期先頭）を実施する（ステップ３２０２）。ストライプ更新処理（周期中盤）については後述する。
　算出結果が１以上ｎ未満であった場合、ストライプ更新処理（周期）３１０４は、ストライプ更新処理（周期中盤）を実施する（ステップ３２０３）。ストライプ更新処理（周期中盤）については後述する。
　算出結果がｎであった場合、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（周期終端前）を実施する（ステップ３２０４）。ストライプ更新処理（周期終端前）については後述する。
　算出結果がｎ＋１であった場合、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（周期終端）を実施する（ステップ３２０５）。ストライプ更新処理（周期終端）については後述する。
　周期については、図１４で示したように、４つのＮｏｄｅ＃０～＃３の構成（ｎ＝３）に、１つのＮｏｄｅ＃４を追加する場合、まず、ストライプ更新処理プログラム１１０２は、周期の先頭のストライプ＃０（サイクル内インデックス＃２０６０＝０）についてストライプ更新処理を実行する。
　次に、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をインクリメントしてｉ＝１で、ステップ３２０１の余りが１となることからステップ３２０３の周期の中盤のストライプ更新処理を実施する。ステップ３２０３では、ストライプ＃１についてストライプ２０３のストライプブロック２０２を更新する。
　次に、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をインクリメントしてｉ＝２で、ステップ３２０１の余りが２となることからステップ３２０３の周期の中盤のストライプ更新処理を実施する。ステップ３２０３では、ストライプ＃２についてストライプ２０３のストライプブロック２０２を更新する。
　次に、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をインクリメントしてｉ＝３で、ステップ３２０１の余りが３＝ｎとなることからステップ３２０４の周期の終端前のストライプ更新処理を実施する。ステップ３２０４では、ストライプ＃３についてストライプ２０３のストライプブロック２０２を更新する。
　次に、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）をインクリメントしてｉ＝４で、ステップ３２０１の余りが４＝ｎ＋１となることからステップ３２０５の周期の終端のストライプ更新処理を実施する。ステップ３２０５では、ストライプ＃４についてストライプ２０３のストライプブロック２０２を更新する。
　以上のように、ＲＡＩＤグループにＮｏｄｅ＃４を追加してストライプ２０３を拡張する際には、Ｎｏｄｅ＃０～＃４にパリティブロックを分散させるストライプ２０３の更新処理をひとつの周期として、繰り返して実行する。
　これにより、図５Ｂで示したストライプ２０３－０～２０３－９にＮｏｄｅ１００を追加する場合には、上述のように、周期先頭のストライプ更新処理（３２０２）から、周期中盤のストライプ更新処理（３２０３）を繰り返してから、周期終端前のストライプ更新処理（３２０４）と周期終端のストライプ更新処理（３２０５）が繰り返して実行される。
　図１８は、ストライプ更新処理（周期先頭）を示す。ストライプ更新処理（周期先頭）は、ストライプ更新処理プログラム１１０２の一部として実施され、各ストライプ２０３のうちストライプ更新処理の周期の先頭に対応するストライプ２０３についてストライプの更新処理を行う。図１４においてはストライプ＃０が周期の先頭となる。
　まず、ストライプ更新処理プログラム１１０２は、次処理ストライプ（Ｓｎ：「Ｓ」は"Ｓｔｒｉｐｅ"、「ｎ」は"ｎｅｘｔ"を表す）を取得する（ステップ３３０１）。次処理ストライプ（Ｓｎ）は、次にストライプ構成の更新処理を行うストライプ２０３を表す。
　なお、ストライプ更新処理プログラム１１０２は、初回の処理であればストライプ管理テーブル１００１を参照して先頭のＳｔｒｉｐｅ＃２０００を次処理ストライプ（Ｓｎ）とする。
　また、ストライプ更新処理プログラム１１０２は、１周期が完了した後の処理であれば、ストライプ管理テーブル１００１を参照して前回のストライプ更新処理の次のＳｔｒｉｐｅ＃２０００を次処理ストライプ（Ｓｎ）とする。また、サイクル内インデックス＃２０６０を「０」にリセットしてから処理を開始する。
　ストライプ更新処理（周期先頭）３２０２では、ストライプ管理テーブル１００１または更新中ストライプ管理テーブル１００９を参照し、未更新のストライプ２０３の中から所定のストライプ２０３を選択してよいが、処理を簡潔にするために、未処理のストライプ２０３の中で、ストライプ＃２０００が最も小さいものを選択することが望ましい。
　次に、ストライプ更新処理プログラム１１０２は、次処理ストライプ（Ｓｎ）内でパリティブロック（Ｐｏ：「Ｐ」は"Ｐａｒｉｔｙ"、「ｏ」は"ｏｌｄ"を表す）が格納されているＮｏｄｅ（Ｎｐ：「Ｎ」は"Ｎｏｄｅ"を表す）の識別子（＃０～＃ｎ）を取得する。なお、以下ではパリティブロック（Ｐｏ）を含むＮｏｄｅ１００をパリティノード（Ｎｐ）とする。
　ストライプ更新処理プログラム１１０２は、パリティＮｏｄｅテーブル１００７のサイクル内インデックス＃２０６０に周期の先頭を示す「０」を設定し、パリティノード２０６１には取得したパリティノード（Ｎｐ）の識別子を登録する（ステップ３３０２）。
　当該パリティＮｏｄｅテーブル１００７は、後述のストライプ更新処理（周期中盤）３２０３で、中間パリティ生成ブロックの選択時に参照される。
　なお、ステップ３３０３以降の処理は、パリティノード（Ｎｐ）と、パリティノード（Ｎｐ）から中間パリティを受信した増設Ｎｏｄｅ１００で実行される。パリティノード（Ｎｐ）と増設Ｎｏｄｅ１００以外のＮｏｄｅ１００は、パリティノード（Ｎｐ）からの処理の完了通知を受信するまで待機する。
　次に、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、パリティノード（Ｎｐ）内の所定のストライプブロック（Ｂｄ：「Ｂ」は"Ｂｌｏｃｋ"、「ｄ」は"ｄａｔａ"を表す）２０２を選択する（ステップ３３０３）。
　当該ストライプブロック（Ｂｄ）は、パリティノードＮｐ内の所定のストライプブロックを選択してよいが、処理を簡潔にするために、パリティノード（Ｎｐ）内のストライプブロック２０２の中で、未更新かつＬＢＡが最も小さいもの等を選択することが望ましい。
　次に、ストライプ更新処理プログラム１１０２は、上記選択されたストライプブロック（Ｂｄ）が、（１）新ストライプ構成で未割当であり、かつ（２）パリティブロックではなく、データブロックであるか否かを判定する（ステップ３３０４）。
　上記いずれかの条件を満たさない場合（ステップ３３０４でＮｏ）、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ステップ３３０３に戻り、異なるストライプブロック（Ｂｄ）を再度選択する。
　上記全ての条件を満たす場合（ステップ３３０４でＹｅｓ）、ストライプ更新処理プログラム１１０２は、増設前のストライプ管理テーブル１００１上で、上記選択されたストライプブロック（Ｂｄ）に対応するストライプ２０３を、次処理ストライプとして図７のストライプ管理テーブル１００１のＮＥＸＴ２００３にフラグを登録する（ステップ３３０５）。
　次に、ストライプ更新処理プログラム１１０２は、パリティノード（Ｎｐ）上で、パリティブロック（Ｐｏ）とストライプブロック（Ｂｄ）から中間パリティ（Ｐｉ：「ｉ」は"ｉｎｔｅｒｍｅｄｉａｔｅ"を表す）を生成し、増設Ｎｏｄｅ（Ｎａ：「ａ」は"ａｄｄｉｔｉｏｎａｌ"を表す）に転送する（ステップ３３０６）。ここで、中間パリティ（Ｐｉ）は、Ｐｏ　ＸＯＲ　Ｂｄで算出される。
　次に、増設Ｎｏｄｅ（Ｎａ）ではストライプ更新処理プログラム１１０２が、パリティノード（Ｎｐ）から中間パリティ（Ｐｉ）を受信する。増設Ｎｏｄｅ（Ｎａ）のストライプ更新処理プログラム１１０２は、増設Ｎｏｄｅ（Ｎａ）内で所定のストライプブロック（Ｂａ）を選択し、中間パリティ（Ｐｉ）を格納する（ステップ３３０７）。
　当該ストライプ更新処理（周期先頭）においては、中間パリティ（Ｐｉ）がそのままパリティブロックとなる。当該ストライプブロック（Ｂａ）は、増設Ｎｏｄｅ（Ｎａ）内の所定のストライプブロックを選択してよいが、処理を簡潔にするために、増設Ｎｏｄｅ（Ｎａ）内のストライプブロックの中で、ＬＢＡが最も小さいもの等を選択することが望ましい。
　次に、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、増設前のストライプ管理テーブル１００１上の次処理ストライプＳｎのうち、パリティノード（Ｎｐ）と、増設Ｎｏｄｅ（Ｎａ）以外のＮｏｄｅ１００に格納されているｎ個のデータブロックと、ストライプブロック（Ｂｄ）と、ストライプブロックＢａ（パリティ）の計ｎ＋１個のストライプブロックを、新ストライプ構成のストライプブロックとして、更新中ストライプ管理テーブル１００９に格納し、ストライプ構成を更新する（ステップ３３０８）。
　次に、ストライプ更新処理プログラム１１０２は、上記ステップ３３０２で選択したパリティブロック（Ｐｏ）を、未割当ブロック（Ｂｎ：「ｎ」は"ｎｏｎ－ａｌｌｏｃａｔｅｄ"を表す）として、未割当ブロック管理テーブル１００８に登録して、周期先頭のストライプ更新処理を終了する。
　周期の先頭のストライプ２０３の処理が完了したので、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ２０３内の他のＮｏｄｅ１００に処理の完了を通知してサイクル内インデックス＃２０６０の値をインクリメントする。また、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１とパリティＮｏｄｅテーブル１００７と、未割当ブロック管理テーブル１００８、更新中ストライプ管理テーブル１００９の各テーブルの差分を他のＮｏｄｅ１００に送信して同期させる。
　以上のように、ストライプ更新処理（周期先頭）では、図１４の（２）のように処理対象のストライプＳｎ（＝＃０）のパリティノード（Ｎｐ）＝３のパリティブロック（Ｐｏ＝Ｐ０）とストライプブロック（Ｂｄ＝Ｄ１）から中間パリティ（Ｐｉ）を演算され、増設Ｎｏｄｅ（Ｎａ）＝＃４に転送される。
　中間パリティ（Ｐｉ）を受信した増設ノード（Ｎａ）では、未処理のストライプブロック（Ｂａ）のうち所定の条件（例えば、ＬＢＡが最小）を満たすストライプブロックに中間パリティ（Ｐｉ）を書き込んで、そのままパリティブロックとする。
　上記処理によって、図１４のストライプ＃０は、Ａ０、Ｂ０、Ｃ０、Ｄ１、Ｐ'０として更新されて更新中ストライプ管理テーブル１００９に登録される。データの移動は、ノード＃３で生成された中間パリティ（Ｐｉ）がノード＃４のパリティブロックＰ'０に転送されるだけである。そのたのストライプブロック＝Ａ０、Ｂ０、Ｃ０、Ｄ１は、移動することなく従前の位置に保持される。
　図１９は、ストライプ更新処理（周期中盤）の一例を示すフローチャートである。
　なお以降、当該図１９のストライプ更新処理（周期中盤）及び、図２０のストライプ更新処理（周期終端前）、図２１のストライプ更新処理（周期終端）は、図１８のストライプ更新処理（周期先頭）と処理が一部重複するため、差異がある部分のみ説明する。
　ストライプ更新処理（周期中盤）は、図１７のステップ３２０３において、ストライプ更新処理プログラム１１０２の一部として実施され、各ストライプ周期の先頭、終端前、及び終端に対応するストライプ以外のストライプ構成の更新を行う。なお、図１４においてはストライプ＃１、＃２が周期の中盤となる。
　まず、ストライプ更新処理プログラム１１０２は、次処理ストライプ（Ｓｎ）を取得する（ステップ３４０１）。ストライプ更新処理（周期中盤）では、次処理ストライプとしストライプ管理テーブル１００１に登録されているストライプ２０３を選択する。
　ストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１を参照し、ＮＥＸＴ２００３に「１」が設定されているエントリのストライプ＃２０００を次処理ストライプ（Ｓｎ）として選択する。
　ストライプ更新処理プログラム１１０２は、次処理ストライプ（Ｓｎ）の選択が完了すると、当該エントリのＮＥＸＴ２００３を「０」にリセットする。
　次の、ステップ３４０２、及びステップ３４０３は、それぞれ図１８のストライプ更新処理（周期先頭）におけるステップ３３０２、及びステップ３３０３と同様である。すなわち、ストライプ更新処理プログラム１１０２は、パリティブロック（Ｐｏ）、パリティノード（Ｎｐ）、ストライプブロック（Ｂｄ）を取得してパリティＮｏｄｅテーブル１００７を更新する。
　なお、ステップ３４０３以降の処理は、パリティノード（Ｎｐ）と、パリティノード（Ｎｐ）から中間パリティを受信したノード（Ｎｎ）で実行される。パリティノード（Ｎｐ）とノード（Ｎｎ）以外のＮｏｄｅ１００は、パリティノード（Ｎｐ）からの処理の完了通知を受信するまで待機する。
　次に、ストライプ更新処理プログラム１１０２は、上記選択されたストライプブロック（Ｂｄ）が、（１）新ストライプ構成で未割当であり、かつ（２）パリティブロックではなく、データブロックであり、かつ（３）増設前のストライプ管理テーブル１００１上で、ストライプブロック（Ｂｄ）が所属するストライプ２０３で、パリティブロックが格納されているＮｏｄｅ１００が、パリティＮｏｄｅテーブル１００７に存在しないかを判定する（ステップ３４０４）。
　上記（３）の判定処理は、各ストライプ２０３のパリティブロックを、周期内の各Ｎｏｄｅ間で均等に分散させるために実施される。すなわち、（３）の判定処理は、図１４の（３）に相当し、ストライプ更新処理プログラム１１０２は、パリティブロック（Ｐｏ＝Ｐ１）を選択し、パリティノード（Ｎｐ＝＃２）を選択し、ストライプブロック（Ｂｄ＝Ｃ２）を選択する。そして、ストライプ更新処理プログラム１１０２は、ストライプブロック（Ｂｄ＝Ｃ２）が所属するストライプ＃２が、パリティＮｏｄｅテーブル１００７に存在するか否かを判定する。
　図１４の（３）の例では、現在処理しているのはストライプ＃１であり、ストライプ＃２は未処理である。従って、パリティＮｏｄｅテーブル１００７にはストライプ＃２がパリティノード＃２０６１として登録されていないので、ステップ３４０５へ進むことになる。
　上記いずれかの条件を満たさない場合（ステップ３４０４でＮｏ）、ストライプ更新処理プログラム１１０２は、ステップ３４０３に戻り、異なるストライプブロック（Ｂｄ）を再度選択する。
　上記全ての条件を満たす場合（ステップ３４０４でＹｅｓ）、ストライプ更新処理プログラム１１０２は、ステップ３４０５を実行する。ステップ３４０５は、図１８のストライプ更新処理（周期先頭）におけるステップ３３０５と同様である。すなわち、ストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１の該当エントリのＮＥＸＴ２００３を「１」設定する。
　次に、ストライプ更新処理プログラム１１０２は、パリティノード（Ｎｐ）で、パリティブロック（Ｐｏ）とストライプブロック（Ｂｄ）の排他的論理和から中間パリティ（Ｐｉ）を生成する。そして、ストライプ更新処理プログラム１１０２は、未割当ブロック（Ｂｎ）の存在するＮｏｄｅ（Ｎｎ）に中間パリティ（Ｐｉ）を転送する（ステップ３４０６）。
　なお、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、未割当ブロック管理テーブル１００８から、Ｎｏｄｅ＃２０７０の値を転送先Ｎｏｄｅ（Ｎｎ）とし、ＬＢＡ＃２０７１を未割当ブロック（Ｂｎ）として中間パリティ（Ｐｉ）を転送する。パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、未割当ブロック管理テーブル１００８で読み込んだエントリをクリアする。
　この処理は図１４の（３）で示したように、パリティノード（Ｎｐ＝＃２）でパリティブロック（Ｐｏ＝Ｐ１）と、ストライプブロック（Ｂｄ＝Ｃ２）の排他的論理和によって中間パリティ（Ｐｉ）が生成される。そして、未割当ブロック管理テーブル１００８に登録されている転送先Ｎｏｄｅ（Ｎｎ＝＃３）の未割当ブロック（Ｂｎ＝Ｐ０）に中間パリティ（Ｐｉ）を転送する。
　次に、転送先Ｎｏｄｅ（Ｎｎ）のストライプ更新処理プログラム１１０２は、受信した中間パリティ（Ｐｉ）と、増設前のストライプ管理テーブル１００１上で次処理ストライプ（Ｓｎ）に対応する転送先Ｎｏｄｅ（Ｎｎ）内のデータブロック（Ｂｏ）から新パリティ（Ｐｎ：「ｎ」は"ｎｅｗ"を表す）を生成する。
　そして、転送先Ｎｏｄｅ（Ｎｎ）のストライプ更新処理プログラム１１０２は、未割当ブロック（Ｂｎ）の領域に新パリティ（Ｐｎ）を格納する（ステップ３４０７）。ここで、新パリティ（Ｐｎ）は、Ｂｏ　ＸＯＲ　Ｐｉで算出される。
　この処理は図１４の（３）で示したように、転送先Ｎｏｄｅ（Ｎｎ＝＃３）で、次処理ストライプ（Ｓｎ＝＃１）に対応するデータブロック（Ｂｏ＝Ｄ１）となる。ストライプ更新処理プログラム１１０２は、中間パリティ（Ｐｉ）とデータブロック（Ｄ１）の排他的論理和から新パリティ（Ｐｎ）を生成する。
　次に、ストライプ更新処理プログラム１１０２は、増設ノード（Ｎａ）に指令して、増設ノード（Ｎａ）内の所定の未割当ストライプブロック（Ｂａ）を選択させる（ステップ３４０８）。
　当該ストライプブロック（Ｂａ）は、増設ノードＮａ内のストライプブロック２０２を選択すればよいが、処理を簡潔にするために、増設ノードＮａ内のストライプブロック２０２の中で、未割り当て、かつ、ＬＢＡが最も小さいもの等を選択することが望ましい。
　次に、パリティノード（Ｎａ）のストライプ更新処理プログラム１１０２は、増設前のストライプ管理テーブル１００１上の次処理ストライプＳｎのうち、パリティノード（Ｎｐ）と、増設ノード（Ｎａ）と、転送先ノード（Ｎｎ）以外のＮｏｄｅ１００に格納されているｎ－１個のデータブロックと、ストライプブロック（Ｂｄ）と、ストライプブロック（Ｂａ）と、未割当ブロック（Ｂｎ）（パリティ）の計ｎ＋１個のストライプブロックを、更新後のストライプＳｎのストライプブロックとして、更新中ストライプ管理テーブル１００９を更新する（ステップ３４０９）。
　この処理は図１４の（３）で示したように、次処理ストライプ（Ｓｎ＝＃１）に対応するストライプブロック２０２は、Ａ１、Ｂ１、Ｃ２、Ｐ'１、Ｅ１として更新される。
　次に、ストライプ更新処理プログラム１１０２は、ステップ３４１０の処理を実行し、処理を終了する。ステップ３４１０は、図１８のストライプ更新処理（周期先頭）におけるステップ３３０９と同様である。
　周期の中盤のストライプ２０３の処理が完了したので、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ２０３内の他のＮｏｄｅ１００に処理の完了を通知してサイクル内インデックス＃２０６０の値をインクリメントする。また、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１とパリティＮｏｄｅテーブル１００７と、未割当ブロック管理テーブル１００８、更新中ストライプ管理テーブル１００９の各テーブルの差分を他のＮｏｄｅ１００に送信して同期させる。
　以上のように、ストライプ更新処理（周期中盤）では、図１４の（３）のように処理対象のストライプＳｎ（＝＃１）のパリティノード（Ｎｐ）＝２のパリティブロック（Ｐｏ＝Ｐ１）とストライプブロック（Ｂｄ＝Ｃ２）から中間パリティ（Ｐｉ）が演算され、転送先ノード（Ｎｎ＝＃３）に転送される。
　中間パリティ（Ｐｉ）を受信した転送先ノード（Ｎｎ＝＃３）では、処理対象のストライプ＃１のデータブロック（Ｂｏ＝Ｄ１）と、中間パリティ（Ｐｉ）から新たなパリティ（Ｐｎ）を生成する。
　そして、転送先ノード（Ｎｎ＝＃３）では、新たなパリティ（Ｐｎ）を未割り当てのストライプブロック（Ｂａ）に書き込んで、増設ノード（Ｎａ）で未割り当てのストライプブロック（Ｂａ）を当該ストライプ＃１についかする。
　上記処理によって、図１４に示す周期中盤のストライプ＃１は、ストライプブロック＝Ａ１、Ｂ１、Ｃ２、Ｐ'１、Ｅ１として更新されて、更新中ストライプ管理テーブル１００９に登録される。データの移動は、ノード＃２で生成された中間パリティ（Ｐｉ）がノード＃３のパリティブロックＰ'１に転送されるだけである。その他のストライプブロック＝Ａ１、Ｂ１、Ｃ２は、移動することなく従前の位置に保持される。
　また、周期中盤の図１４のストライプ＃２も同様に処理されて、ストライプブロック＝Ａ２、Ｂ３、Ｐ'２、Ｄ２、Ｅ２として更新されて、更新中ストライプ管理テーブル１００９に登録される。
　データの移動は、ノード＃１で生成された中間パリティ（Ｐｉ）がノード＃２のパリティブロックＰ'２に転送されるだけである。その他のストライプブロック＝Ａ２、Ｂ３、Ｐ'２、Ｄ２、Ｅ２は、移動することなく従前の位置に保持される。
　図２０は、ストライプ更新処理（周期終端前）の一例を示すフローチャートである。ストライプ更新処理（周期終端前）は、図１７のステップ３２０４において、ストライプ更新処理プログラム１１０２の一部として実施され、各ストライプ周期の終端の一つ前のストライプで構成の更新を行う。
　ストライプ更新処理（周期終端前）においては、ステップ３５０１、３５０３、３５０４はストライプ更新処理（周期先頭）のステップ３３０１、３３０３、３３０４と同様であり、ステップ３５０２とステップ３５０４以外は、ストライプ更新処理（周期中盤）と同様である。
　ステップ３５０２では、ストライプ更新処理プログラム１１０２は、次処理ストライプ（Ｓｎ）内のパリティブロック（Ｐｏ）が格納されているパリティノード（Ｎｐ）を取得する。
　上記ストライプ更新処理（周期先頭）、及びストライプ更新処理（周期中盤）では、ストライプ更新処理プログラム１１０２が、次処理ストライプ（Ｓｎ）を適切に選択するため、当該取得したパリティノード（Ｎｐ）をパリティＮｏｄｅテーブル１００７に登録したが、ストライプ更新処理（終端前）では、次処理ストライプ（Ｓｎ）が一意に定まるため、パリティＮｏｄｅテーブル１００７への登録は不要である。
　なお、次処理ストライプ（Ｓｎ）は、図１９のストライプ更新処理（周期中盤）で処理したストライプ２０３の次のストライプを処理対象として、ストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１から選択してもよい。
　なお、ステップ３５０３以降の処理は、パリティノード（Ｎｐ）と、パリティノード（Ｎｐ）から中間パリティを受信したノード（Ｎｎ）で実行される。パリティノード（Ｎｐ）とノード（Ｎｎ）以外のＮｏｄｅ１００は、パリティノード（Ｎｐ）からの処理の完了通知を受信するまで待機する。
　ステップ３５０５～３５１０は、上記図１９に示したストライプ更新処理（周期先頭）のステップ３４０５～３４１０と様である。
　上記処理によって、周期終端前の図１４のストライプ＃３は、ストライプブロック＝Ｐ'４、Ｂ４、Ｃ４、Ｄ４、Ｅ４として更新されて、更新中ストライプ管理テーブル１００９に登録される。
　周期の終端のひとつ前のストライプ２０３の処理が完了したので、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ２０３内の他のＮｏｄｅ１００に処理の完了を通知してサイクル内インデックス＃２０６０の値をインクリメントする。また、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１とパリティＮｏｄｅテーブル１００７と、未割当ブロック管理テーブル１００８、更新中ストライプ管理テーブル１００９の各テーブルの差分を他のＮｏｄｅ１００に送信して同期させる。
　データの移動は、ノード＃０で生成された中間パリティ（Ｐｉ）がノード＃１のパリティブロックＰ'３に転送されるだけである。その他のストライプブロック＝Ａ４、Ｃ３、Ｄ３、Ｅ３は、移動することなく従前の位置に保持される。
　図２１は、ストライプ更新処理（周期終端）の一例を示すフローチャートである。
　ストライプ更新処理（周期終端）は、図１７のステップ３２０５において、ストライプ更新処理プログラム１１０２の一部として実施され、各ストライプ周期の終端のストライプ構成の更新を行う。
　まず、ストライプ更新処理プログラム１１０２は、ステップ３６０１の処理を実行する。ステップ３６０１では、図２０のストライプ更新処理（周期終端前）で処理したストライプ２０３の次のストライプを処理対象としてストライプ管理テーブル１００１から選択する。
　次に、ストライプ更新処理プログラム１１０２は、次処理ストライプ（Ｓｎ）内のパリティブロック（Ｐｏ）をデータブロック（Ｂｃ：「ｃ」は"ｃｈａｎｇｅｄ"を表す）に変更する（ストライプ３６０２）。この処理は、増設されたＮｏｄｅ＃４を含めてパリティブロック（Ｐｏ）を各Ｎｏｄｅ１００に分散して格納しようとした場合に、周期内で少なくとも１ストライプのパリティブロック（Ｐｏ）を増設Ｎｏｄｅに格納し（ストライプ更新処理（周期先頭）で実施済み）、かつ周期内で少なくとも１ストライプのパリティブロックをデータブロックに変更する必要があるためである。
　なお、ステップ３６０２以降の処理は、パリティノード（Ｎｐ）と、パリティノード（Ｎｐ）から中間パリティを受信した転送先ノード（Ｎｎ）で実行される。パリティノード（Ｎｐ）と転送先ノード（Ｎｎ）以外のＮｏｄｅ１００は、パリティノード（Ｎｐ）からの処理の完了通知を受信するまで待機する。
　次に、ストライプ更新処理プログラム１１０２は、当該データブロック（Ｂｃ）を、未割当ブロックの存在する転送先Ｎｏｄｅ（Ｎｎ）に転送する（ステップ３６０３）。
　次に、ストライプ更新処理プログラム１１０２は、転送先ノード（Ｎｎ）上で、当該データブロック（Ｂｃ）と、増設前のストライプ管理テーブル１００１上で次処理ストライプ（Ｓｎ）に対応する転送先ノード（Ｎｎ）内のデータブロック（Ｂｏ）から、新パリティ（Ｐｎ：「ｎ」は"ｎｅｗ"を表す）を生成する。ストライプ更新処理プログラム１１０２は、生成した新パリティ（Ｐｎ）を、未割当ブロック（Ｂｎ）が格納されていた領域に格納する（ステップ３６０４）。ここで、新パリティ（Ｐｎ）は、Ｂｏ　ＸＯＲ　Ｂｃで算出される。
　次の、ステップ３６０５は、図１９のストライプ更新処理（周期中盤）におけるステップ３４０８と同様である。すなわち、ストライプ更新処理プログラム１１０２は、増設ノード（Ｎａ）に指令して、増設ノード（Ｎａ）内の所定の未割当ストライプブロック（Ｂａ）を選択させる。増設ノード（Ｎａ）は、選択したストライプブロック２０２の位置（ＬＢＡ）を応答する。
　次に、ストライプ更新処理プログラム１１０２は、増設前のストライプ管理テーブル１００１上の次処理ストライプ（Ｓｎ）のうち、パリティノード（Ｎｐ）、増設ノード（Ｎａ）、転送先ノード（Ｎｎ）以外のＮｏｄｅに格納されているｎ－１個のデータブロック、Ｂｃ、Ｂａ、Ｂｎ（パリティ）の計ｎ＋１個のストライプブロックを、新ストライプ上の次処理ストライプ（Ｓｎ）のストライプブロック２０２として選択し、更新中ストライプ管理テーブル１００９を更新する（ステップ３６０６）。
　次に、ストライプ更新処理プログラム１１０２は、パリティＮｏｄｅテーブル１００７と、ストライプ管理テーブル１００１のＮＥＸＴ２００３の次処理ストライプをクリアし、処理を終了する（ステップ３６０７）。
　周期の終端のストライプ２０３の処理が完了したので、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ２０３内の他のＮｏｄｅ１００に処理の完了を通知してサイクル内インデックス＃２０６０の値をインクリメントする。また、パリティノード（Ｎｐ）のストライプ更新処理プログラム１１０２は、ストライプ管理テーブル１００１とパリティＮｏｄｅテーブル１００７と、未割当ブロック管理テーブル１００８、更新中ストライプ管理テーブル１００９の各テーブルの差分を他のＮｏｄｅ１００に送信して同期させる。
　上記処理によって、図１４の例では（３）で示すように、周期の終端の次処理ストライプとしてストライプ＃４が選択され、パリティブロック（Ｐｏ）としてノード＃３のパリティブロックＰ４が選択される。このパリティブロックＰ４は、データブロックＤ４に書き換えられる。なお、本実施例１では、書き換えるデータブロックＤ４の値は所定値である「０」とする。
　次に、データブロックＤ４の値は、未割り当てブロック（Ｂｎ＝Ｐ３）を有するノード＃０に転送される。そして、旧ストライプ構成（＝ストライプ＃４）のデータブロックＢ４、Ｃ４と、転送されたデータブロックＤ４の値の排他的論理和から新たなパリティ（Ｐｎ）が生成され、ノード＃０の未割り当てブロック（Ｂｎ＝Ｐ'４）に格納される。
　増設ノード（Ｎａ）内の未割り当てのストライプブロック（Ｂａ＝Ｅ４）が選択される。そして、旧ストライプ構成の次処理ストライプ＃４で、ｎ－１個（２個）のデータブロックＢ４、Ｃ４と、書き換えられたデータブロックＤ４と、増設ノード（Ｎａ）のデータブロックＥ４と、転送先ノード（Ｎｎ）の新パリティ（Ｐｎ）が、新たなストライプ＃４のストライプブロック２０２として、更新中ストライプ管理テーブル１００９に格納される。
　図２２は、ストライプ更新処理（端数）の一例を示すフローチャートである。この処理は、図１６のステップ３１０７で実行される。ストライプ更新処理（端数）は、ストライプ更新処理プログラム１１０２の一部として実施され、計算機システム１内で処理対象のストライプのうち、ストライプ構成の更新周期数（ｎ＋２）に満たない端数のストライプ２０３の更新を行う。
　ストライプ更新処理（端数）は、端数となるストライプ数が１かそれ以外かで処理が異なる。そのため、まずストライプ更新処理プログラム１１０２は、端数となるストライプ数を算出する（ステップ３７０１）。具体的には、Ｓ　ｍｏｄ　（ｎ＋２）が１であるか否かを判定すればよい。
　端数となるストライプ数が１である場合（ステップ３７０１でＹｅｓ）、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（端数１）を実施する（ステップ３７０２）。ストライプ更新処理（端数１）については後述する。
　端数となるストライプ数が２以上である場合（ステップ３７０１でＮｏ）、ストライプ更新処理プログラム１１０２は、ストライプ更新処理（端数２以上）を実施する（ステップ３７０３）。ストライプ更新処理（端数２以上）については後述する。
　図２３は、ストライプ更新処理（端数１）の一例を示すフローチャートである。この処理は、図２２のステップ３７０２で実行される。ストライプ更新処理（端数）は、ストライプ更新処理プログラム１１０２の一部として実施され、計算機システム１内で処理対象のストライプ２０３のうち、ストライプ構成の更新周期数に満たない端数のストライプの数が１の場合に、当該端数ストライプ構成の更新（端数１）を行う。
　まず、ストライプ更新処理プログラム１１０２は、増設Ｎｏｄｅ（Ｎａ）上の、未割当ストライプブロック（Ｂａ）を選択する（ステップ３８０１）。ストライプ更新処理（端数１）では、未更新のストライプ数が１つであるので、当該未割当ストライプブロック（Ｂａ）は、一意に定まる。
　次に、ストライプ更新処理プログラム１１０２は、増設前のストライプ管理テーブル１００１上の次処理ストライプ（Ｓｎ）に対応する計ｎ＋１個のデータブロックおよびパリティブロック（Ｐｏ）と、未割当ストライプブロック（Ｂａ）の計ｎ＋２個のストライプブロックを、新ストライプ構成の次処理ストライプ（Ｓｎ）のストライプブロック２０２として、更新中ストライプ管理テーブル１００９を更新し（ステップ３８０２）、処理を終了する。
　なお、未割当ストライプブロック（Ｂａ）には所定値のゼロが格納されているため、増設前のストライプ管理テーブル１００１上のパリティブロック（Ｐｏ）は、更新後も同じ値を使用可能である。
　図２４は、ストライプ更新処理（端数２以上）の一例を示すフローチャートである。この処理は、図２３のステップ３７０３で実行される。ストライプ更新処理（端数２以上）は、ストライプ更新処理プログラム１１０２の一部として実施され、計算機システム１内で処理対象のストライプ２０３のうち、ストライプ構成の更新周期数（ｎ＋２）に満たない端数のストライプの数が２以上の場合に、当該端数ストライプ構成の更新を行う。
　以下では、端数となるストライプの数をｋ（＝Ｓ　ｍｏｄ　（ｎ＋２））とする。すなわち、２≦ｋ＜ｎ＋２である。
　まず、ストライプ更新処理プログラム１１０２は、ストライプイテレータ（ｉ）を参照し、ｉ　ｍｏｄ　（ｎ＋２）の値を算出する（ステップ３９０１）。
　算出結果が０であった場合、ストライプ更新処理プログラム１１０２は、図１８に示したストライプ更新処理（周期先頭）を実施する（ステップ３９０２）。
　算出結果が１以上かつｋ－２未満であった場合、図１９に示したストライプ更新処理プログラム１１０２は、ストライプ更新処理（周期中盤）を実施する（ステップ３９０３）。
　算出結果がｋ－１であった場合、ストライプ更新処理プログラム１１０２は、図２０に示したストライプ更新処理（周期終端前）を実施する（ステップ３９０４）。
　算出結果がｋであった場合、ストライプ更新処理プログラム１１０２は、図２１に示したストライプ更新処理（周期終端）を実施する（ステップ３９０５）。
　上記処理によって、ストライプ構成の更新周期数（ｎ＋２）に満たない端数のストライプ２０３についてストライプ構成の更新が行われる。
　図２５は、本実施例１に係る、Ｎｏｄｅ障害時のリビルド処理の一例を示すフローチャートである。
　リビルド処理プログラム１１０３は、計算機システム１が、いずれかのＮｏｄｅ１００の障害を検出した場合に自動的に実行される。或いはＮｏｄｅ１００のいずれかに障害が発生した後、管理サーバ２０の指示によって実行される。本実施例１では、スペアのＮｏｄｅ１００（以下では、スペアＮｏｄｅとする）に対してデータを復旧する例を示す。
　まず、リビルド処理プログラム１１０３は、障害が発生したＮｏｄｅ１００の識別子を障害Ｎｏｄｅ＃として取得する（ステップ４００１）。次に、リビルド処理プログラム１１０３は、リビルド対象のストライプ番号をＳｔｒｉｐｅ＃として取得する（ステップ４００２）。リビルド対象のストライプ＃は、リビルド処理未実施のストライプ２０３のうち、Ｓｔｒｉｐｅ＃の最も小さいものを選択する。
　次に、リビルド処理プログラム１１０３は、ストライプ管理テーブル１００１を参照し、当該Ｓｔｒｉｐｅ＃に対応する、各Ｎｏｄｅ内のストライプブロックのＬＢＡを取得する（ステップ４００３）。
　次に、リビルド処理プログラム１１０３は、ステップ４００３にてＬＢＡにより特定された複数のデータ（データブロック及びパリティブロック）を、各Ｎｏｄｅ１００からスペアＮｏｄｅに転送し、ロストしたデータを復旧する（ステップ４００４）。
　次に、リビルド処理プログラム１１０３は、当該復旧したデータをスペアＮｏｄｅ内の所定の領域に格納し、ストライプ管理テーブル１００１を更新する（ステップ４００５）。
　次に、リビルド処理プログラム１１０３は、コピーポインタ１０１０を更新する（ステップ４００６）。当該コピーポインタ１０１０は、例えばホスト１０から発行されたＲｅａｄ要求に対して、対象のデータをスペアＮｏｄｅから取得するか、またはコレクションリードにより取得するか否かを判定するのに使用される変数である。
　具体的には、当該コピーポインタ１０１０よりもＳｔｒｉｐｅ＃が小さいストライプ２０３内のデータに対してＲｅａｄ要求が発行された場合、当該Ｓｔｒｉｐｅ＃に対応するストライプブロックは全て復旧済みであるから、ストライプ管理テーブル１００１に従ってＲｅａｄ対象データを取得し、要求元に応答すればよい。
　一方、当該コピーポインタ１０１０よりもＳｔｒｉｐｅ＃が大きいストライプ内のデータであり、かつ対応するＮｏｄｅ１００がＮｏｄｅ管理テーブル１００２上で障害状態にある場合は、ストライプ管理テーブル１００１に従って、当該対象データ以外の、復旧に必要となる一定数のストライプブロックを取得し、復旧処理を行った後、要求元に応答すればよい。
　次に、リビルド処理プログラム１１０３は、復旧対象のストライプ２０３のリビルド処理が完了したか否かを判定する（ステップ４００７）。復旧対象のストライプ２０３のリビルド処理が完了していない場合（ステップ４００７でＮｏ）は、ステップ４００２に戻って、リビルド対象のＳｔｒｉｐｅ＃を再選択する。復旧対象のストライプ２０３のリビルド処理が完了した場合（ステップ４００７でＹｅｓ）は、処理を終了する。
　以上のように、本実施例１によれば、増設Ｎｏｄｅ１００を追加してストライプ２０３を拡張する場合に、ストライプ更新処理プログラム１１０２が、１つのストライプ２０３について少なくともひとつのストライプブロック２０２を他のＮｏｄｅ１００へ移動することで、ストライプ構成を更新することができる。
　すなわち、本実施例１では、ストライプ更新処理プログラム１１０２が、ひとつのＮｏｄｅ１００内で中間パリティを生成して、当該中間パリティのパリティブロックを他のＮｏｄｅ１００に転送し、中間パリティを受信したＮｏｄｅ１００では中間パリティとＮｏｄｅ１００内の既存のデータで新パリティを生成する。
　したがって、本実施例１では、Ｎｏｄｅ１００を増設して、ストライプ構成を拡張する際には、Ｎｏｄｅ１００間のデータ移動量を全容量の１／Ｎ（Ｎはシステム内のＮｏｄｅ数）に削減することが可能となる。これにより、Ｎｏｄｅ１００間のネットワーク帯域の狭いＳｃａｌｅ－ｏｕｔ構成においても、高速に容量効率を改善することができる。
　また、ストライプ２０３内の全てのデータブロックについて移動させる必要は無いので、パリティの演算負荷を低減することが可能となる。
　図２６は、実施例２を示し、管理サーバ２０の一例を示すブロック図である。前記実施例１では、Ｎｏｄｅ１００が主体となってストライプ更新処理プログラム１１０２を実施する例を示したが、本実施例２では、管理サーバ２０が主体となってストライプ更新処理プログラム１１０２を実施する例を示す。
　管理サーバ２０は、演算処理を行うＣＰＵ２１と、プログラムやデータを格納するメモリ２２と、ネットワーク３０を介して各Ｎｏｄｅ１００に接続される管理Ｉ／Ｆ２３とを含む。
　メモリ２２には、各種プログラムを格納する制御プログラム格納領域２２２と、各種情報を格納する制御情報格納領域２２１が設定される。
　制御プログラム格納領域２２２は、前記実施例１と同様の、Ｎｏｄｅ増設処理プログラム１１０１と、ストライプ更新処理プログラム１１０２と、リビルド処理プログラム１１０３とを格納する。なお、前記実施例１に示したＩ／Ｏ処理プログラム１１０４は、各Ｎｏｄｅ１００で実行される。
　制御情報格納領域２２１は、前記実施例１と同様の、ストライプ管理テーブル１００１と、Ｎｏｄｅ管理テーブル１００２と、ドライブ管理テーブル１００３と、Ｐｏｏｌ　Ｖｏｌｕｍｅ管理テーブル１００４と、Ｐｏｏｌ管理テーブル１００５と、ＶＶＯＬ管理テーブル１００６と、パリティＮｏｄｅテーブル１００７と、更新中ストライプ管理テーブル１００９と、未割当ブロック管理テーブル１００８と、コピーポインタ１０１０とを格納する。
　なお、パリティＮｏｄｅテーブル１００７と、未割当ブロック管理テーブル１００８と、コピーポインタ１０１０は、各Ｎｏｄｅ１００毎に設定される。
　管理サーバ２０は、Ｎｏｄｅ増設処理プログラム１１０１及びストライプ更新処理プログラム１１０２を実行して、Ｎｏｄｅ１００の増設時にはストライプ構成の更新を各Ｎｏｄｅ１００に指令する。処理の内容は、前記実施例１と同様であるので、説明は省略する。
　本実施例２においても、ストライプ構成を拡張する際のＮｏｄｅ１００間のデータ移動量を全容量の１／Ｎ（Ｎはシステム内のＮｏｄｅ数）に削減することが可能となる。
　＜まとめ＞
　上記実施例１、２では、複数のＮｏｄｅ１００でＲＡＩＤグループを構成した場合を示したが、複数の記憶ドライブ１６０でＲＡＩＤグループを構成したストレージ装置に本実施例を適用しても良い。この場合、増設用の記憶ドライブ１６０を追加した際に、ストライプ構成の構成を上記実施例１、２と同様に行うことができる。
　すなわち、ノードが記憶領域を提供する計算機や記憶ドライブのいずれで構成されても、本発明を適用することが可能となる。ノードが記憶領域を提供する計算機の場合は上記実施例１、２のように、各Ｎｏｄｅ１００や管理サーバ２０でストライプ更新処理を実施すれば良い。また、ノードが記憶領域を提供する記憶ドライブの場合には、ノードを制御するプロセッサが、複数の記憶ドライブで構成されたストライプの更新処理を実施すればよい。
　なお、本発明は上記した各実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。
　また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

Claims (9)

  1. 　プロセッサと、メモリと、記憶領域とを含むノードを複数有し、複数の前記ノードでデータブロックとパリティブロックとを含んでストライプを構成するストレージシステムであって、
    　前記プロセッサは、前記ストライプの更新処理を行う場合に、
    　第１のノードに含まれるデータブロックと、前記第１のノードに含まれかつ処理対象ストライプに含まれるパリティブロックとから、中間パリティを生成し、
    　前記中間パリティを、第２のノードに転送し、前記第２のノードのブロックにパリティとして格納させ、
    　前記中間パリティを生成する基となったデータブロックと、前記パリティを格納したブロックと、前記第１及び第２のノード以外の処理対象ストライプ内のデータブロックと、でストライプを構成する
    　ことを特徴とするストレージシステム。
  2. 　請求項１に記載のストレージシステムであって、
    　前記パリティを格納する第２のノードは、前記更新処理前に前記処理対象ストライプのデータブロックを格納していないノードである
    　ことを特徴とするストレージシステム。
  3. 　請求項１に記載のストレージシステムであって、
    　前記第２のノードに含まれかつ前記処理対象ストライプに含まれるデータブロックと前記中間パリティとから、パリティを生成して、前記第２のノードに格納し、
    　前記ストライプの構成では、さらに、前記更新処理前には前記処理対象ストライプのデータブロックを格納していないノードに含まれる追加データブロックを含む
    　ことを特徴とするストレージシステム。
  4. 　請求項３に記載のストレージシステムであって、
    　前記追加データブロックは、前記パリティの値に影響しない所定のデータを格納する
    　ことを特徴とするストレージシステム。
  5. 　請求項１に記載のストレージシステムであって、
    　前記ストライプを構成した場合に、前記処理対象ストライプを解除する
    　ことを特徴とするストレージシステム。
  6. 　請求項１に記載のストレージシステムであって、
    　前記中間パリティを生成する基となったデータブロックは、前記処理対象ストライプの更新処理後に、当該構成したストライプと、他のストライプとに所属し、
    　前記他のストライプが処理対象ストライプとして更新処理された場合に、前記他のストライプから除外されることを特徴とする
    　ことを特徴とするストレージシステム。
  7. 　請求項６に記載のストレージシステムであって、
    　前記パリティは、前記処理対象ストライプの更新処理よりも前の更新処理で他のストライプより除外されたブロックに格納されることを特徴とする
    　ことを特徴とするストレージシステム。
  8. 　請求項１に記載のストレージシステムであって、
    　前記ノードが追加された場合に、複数のストライプに前記更新処理を行う
    　ことを特徴とするストレージシステム。
  9. 　プロセッサと、メモリと、記憶領域とを含むノードを複数有し、複数の前記ノードでデータブロックとパリティブロックとを含んでストライプを構成するストレージシステムの制御方法であって、
    　前記プロセッサは、前記ストライプの更新処理を行う場合に、
    　第１のノードに含まれるデータブロックと、第１のノードに含まれかつ処理対象ストライプに含まれるパリティブロックとから、中間パリティを生成し、中間パリティ生成工程と、
    　前記中間パリティを、第２のノードに転送し、前記第２のノードのブロックにパリティとして格納させるパリティ格納工程と、
    　前記中間パリティを生成する基となったデータブロックと、前記パリティを格納したブロックと、前記第１及び第２のノード以外の処理対象ストライプ内のデータブロックと、でストライプを構成するストライプ構成工程と、
    　を行うことを特徴とするストレージシステムの制御方法。 
PCT/JP2017/022160 2017-06-15 2017-06-15 ストレージシステム及びストレージシステムの制御方法 WO2018229944A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/327,349 US10713117B2 (en) 2017-06-15 2017-06-15 Storage system and method for controlling storage system
PCT/JP2017/022160 WO2018229944A1 (ja) 2017-06-15 2017-06-15 ストレージシステム及びストレージシステムの制御方法
JP2019524668A JP6807457B2 (ja) 2017-06-15 2017-06-15 ストレージシステム及びストレージシステムの制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/022160 WO2018229944A1 (ja) 2017-06-15 2017-06-15 ストレージシステム及びストレージシステムの制御方法

Publications (1)

Publication Number Publication Date
WO2018229944A1 true WO2018229944A1 (ja) 2018-12-20

Family

ID=64660764

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/022160 WO2018229944A1 (ja) 2017-06-15 2017-06-15 ストレージシステム及びストレージシステムの制御方法

Country Status (3)

Country Link
US (1) US10713117B2 (ja)
JP (1) JP6807457B2 (ja)
WO (1) WO2018229944A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022101208A (ja) * 2020-12-24 2022-07-06 株式会社日立製作所 分散型ストレージシステム、データ復旧方法、及びデータ処理プログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11099753B2 (en) * 2018-07-27 2021-08-24 EMC IP Holding Company LLC Method and apparatus for dynamic flow control in distributed storage systems
US11593206B2 (en) * 2021-01-19 2023-02-28 EMC IP Holding Company LLC Distributed raid rebuild

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5191584A (en) * 1991-02-20 1993-03-02 Micropolis Corporation Mass storage array with efficient parity calculation
WO2003077111A1 (fr) * 2002-03-13 2003-09-18 Fujitsu Limited Controleur pour dispositif raid
US20080276041A1 (en) * 2007-05-01 2008-11-06 International Business Machines Corporation Data storage array scaling method and system with minimal data movement
JP2013196276A (ja) * 2012-03-19 2013-09-30 Fujitsu Ltd 情報処理装置、プログラムおよびデータ配置方法
JP2014203233A (ja) * 2013-04-04 2014-10-27 株式会社日立製作所 ストレージシステム及びストレージシステムにおいてデータを更新する方法
JP2015515033A (ja) * 2012-04-27 2015-05-21 株式会社日立製作所 ストレージシステム
WO2016051512A1 (ja) * 2014-09-30 2016-04-07 株式会社日立製作所 分散型ストレージシステム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4792490B2 (ja) 2008-09-08 2011-10-12 株式会社日立製作所 記憶制御装置及びｒａｉｄグループの拡張方法
US8799746B2 (en) * 2012-06-13 2014-08-05 Caringo, Inc. Erasure coding and replication in storage clusters
US9317436B2 (en) * 2013-06-21 2016-04-19 Hewlett Packard Enterprise Development Lp Cache node processing
US9529675B2 (en) * 2013-07-26 2016-12-27 Huawei Technologies Co., Ltd. Data recovery method, data recovery device and distributed storage system
US9921910B2 (en) * 2015-02-19 2018-03-20 Netapp, Inc. Virtual chunk service based data recovery in a distributed data storage system
CN105095013B (zh) * 2015-06-04 2017-11-21 华为技术有限公司 数据存储方法、恢复方法、相关装置以及系统
CN107844268B (zh) * 2015-06-04 2021-09-14 华为技术有限公司 一种数据分发方法、数据存储方法、相关装置以及系统
WO2017061008A1 (ja) * 2015-10-08 2017-04-13 株式会社日立製作所 ストレージシステム
US9921914B2 (en) * 2015-11-03 2018-03-20 Intel Corporation Redundant array of independent disks (RAID) write hole solutions
EP3404527B1 (en) * 2016-02-18 2023-08-30 Huawei Technologies Co., Ltd. Data updating technique
KR20180051703A (ko) * 2016-11-07 2018-05-17 삼성전자주식회사 Raid 방식으로 데이터를 저장하는 스토리지 장치
SG11201901608VA (en) * 2017-03-29 2019-03-28 Huawei Tech Co Ltd Method for accessing distributed storage system, related apparatus, and related system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5191584A (en) * 1991-02-20 1993-03-02 Micropolis Corporation Mass storage array with efficient parity calculation
WO2003077111A1 (fr) * 2002-03-13 2003-09-18 Fujitsu Limited Controleur pour dispositif raid
US20080276041A1 (en) * 2007-05-01 2008-11-06 International Business Machines Corporation Data storage array scaling method and system with minimal data movement
JP2013196276A (ja) * 2012-03-19 2013-09-30 Fujitsu Ltd 情報処理装置、プログラムおよびデータ配置方法
JP2015515033A (ja) * 2012-04-27 2015-05-21 株式会社日立製作所 ストレージシステム
JP2014203233A (ja) * 2013-04-04 2014-10-27 株式会社日立製作所 ストレージシステム及びストレージシステムにおいてデータを更新する方法
WO2016051512A1 (ja) * 2014-09-30 2016-04-07 株式会社日立製作所 分散型ストレージシステム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022101208A (ja) * 2020-12-24 2022-07-06 株式会社日立製作所 分散型ストレージシステム、データ復旧方法、及びデータ処理プログラム
JP7137612B2 (ja) 2020-12-24 2022-09-14 株式会社日立製作所 分散型ストレージシステム、データ復旧方法、及びデータ処理プログラム

Also Published As

Publication number Publication date
JP6807457B2 (ja) 2021-01-06
US10713117B2 (en) 2020-07-14
JPWO2018229944A1 (ja) 2019-11-07
US20190196908A1 (en) 2019-06-27

Similar Documents

Publication Publication Date Title
US11327661B2 (en) Storage system and data management method
JP6560759B2 (ja) ストレージシステム
US11137940B2 (en) Storage system and control method thereof
US10372538B2 (en) Computer system
US20170212705A1 (en) Dynamic Weighting for Distributed Parity Device Layouts
US10678470B2 (en) Computer system,control method for physical storage device,and recording medium
US20190243553A1 (en) Storage system, computer-readable recording medium, and control method for system
US20190196911A1 (en) Computer system
US10705907B1 (en) Data protection in a heterogeneous random access storage array
US10579540B2 (en) Raid data migration through stripe swapping
US11150820B2 (en) Storage system and storage management method
CN112764661A (zh) 用于管理存储系统的方法、设备和计算机程序产品
JP6807457B2 (ja) ストレージシステム及びストレージシステムの制御方法
US11880278B2 (en) Storage system and storage administration method
US11809274B2 (en) Recovery from partial device error in data storage system
US11467904B2 (en) Storage system and control method of the same
US11544005B2 (en) Storage system and processing method
WO2018131067A1 (ja) 記憶ドライブの故障により消失したデータを復元する装置

Legal Events

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

Ref document number: 17913573

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019524668

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17913573

Country of ref document: EP

Kind code of ref document: A1