WO2014132373A1 - ストレージシステム及び記憶デバイス障害回復方法 - Google Patents

ストレージシステム及び記憶デバイス障害回復方法 Download PDF

Info

Publication number
WO2014132373A1
WO2014132373A1 PCT/JP2013/055282 JP2013055282W WO2014132373A1 WO 2014132373 A1 WO2014132373 A1 WO 2014132373A1 JP 2013055282 W JP2013055282 W JP 2013055282W WO 2014132373 A1 WO2014132373 A1 WO 2014132373A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
recovery
storage device
drive
storage
Prior art date
Application number
PCT/JP2013/055282
Other languages
English (en)
French (fr)
Inventor
亮真 石坂
智久 小笠原
幸良 高村
裕介 松村
Original Assignee
株式会社 日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社 日立製作所 filed Critical 株式会社 日立製作所
Priority to US14/764,397 priority Critical patent/US20150378858A1/en
Priority to PCT/JP2013/055282 priority patent/WO2014132373A1/ja
Publication of WO2014132373A1 publication Critical patent/WO2014132373A1/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/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/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
    • G06F11/1088—Reconstruction on already foreseen single or plurality of spare disks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/85—Active fault masking without idle spares

Definitions

  • the present invention relates to a storage system and a storage device failure recovery method.
  • the storage system includes a number of storage devices such as HDDs (Hard Disk Drives) arranged in an array.
  • the logical configuration of this storage device is constructed on the basis of RAID (Redundant Array of Independent (Inexpensive) Disks) and maintains the reliability of the storage system.
  • the host computer can read / write data from / to the storage device by issuing a write or read I / O access command to the storage system.
  • Patent Document 1 when an HDD failure occurs, the power is turned on / off before or after the HDD is blocked, and when the HDD is restored, the operation using the restored HDD is resumed. Has been.
  • Patent Document 1 a hard reset is executed after the HDD is blocked in accordance with the type of failure, and when the recovery is performed, the use of the disk is resumed. It is disclosed that the difference is reflected on the disk after recovery.
  • the HDD is restarted without being blocked in the case of a specific failure, blocked when not recovered, and the read during the restart of the failed HDD uses data and parity of the HDD in the same RAID group.
  • a write during restart of a failed HDD is written to a spare disk, and data is written back to the disk after recovery from the failure by restart.
  • Patent Document 3 discloses that the time required for data recovery to the HDD is shortened by using a collection copy process and a copy back process in combination.
  • An object of the present invention is to provide a storage system and a storage device failure recovery method capable of reducing the recovery time from a failure while guaranteeing data reliability.
  • a recovery process corresponding to the content of the failure is executed for the storage device that has been blocked due to the failure. Then, the storage device restored by executing the recovery process is inspected according to the storage system operating status or the failure history of the restored storage device.
  • FIG. 1 is a diagram illustrating the concept of the present invention.
  • FIG. 2 is a configuration diagram of the storage system.
  • FIG. 3 is a diagram illustrating a configuration example of an error factor determination table.
  • FIG. 4 is a diagram illustrating a configuration example of the recovery count management table.
  • FIG. 5 is a diagram illustrating a configuration example of the recovery operation determination table.
  • FIG. 6 is a flowchart illustrating the recovery operation and the inspection process according to the first embodiment.
  • FIG. 7 is a flowchart illustrating the error factor confirmation process in the first embodiment.
  • FIG. 8 is a diagram illustrating a first recovery operation of the failed drive.
  • FIG. 9 is a diagram illustrating a second recovery operation of the failed drive.
  • FIG. 1 is a diagram illustrating the concept of the present invention.
  • FIG. 2 is a configuration diagram of the storage system.
  • FIG. 3 is a diagram illustrating a configuration example of an error factor determination table.
  • FIG. 4 is a diagram illustrating
  • FIG. 10 is a diagram illustrating a configuration example of the maximum recovery number determination table.
  • FIG. 11 is a diagram illustrating a configuration example of the examination content determination table.
  • FIG. 12 is a diagram illustrating a configuration example of an error threshold determination table.
  • FIG. 13 is a flowchart illustrating the recovery operation and the inspection process according to the second embodiment.
  • FIG. 14 is a flowchart illustrating error factor confirmation processing according to the second embodiment.
  • FIG. 15 is a diagram illustrating a configuration example of a data recovery area management table in a failed drive.
  • FIG. 16 is a diagram illustrating a configuration example of a data recovery area management table in the spare drive.
  • FIG. 17 is a diagram illustrating a third recovery operation of the failed drive.
  • FIG. 18 is a diagram illustrating the data and parity update operation in the fourth recovery operation of the failed drive.
  • FIG. 19 is a diagram showing data recovery processing in the fourth recovery operation of the failed drive.
  • FIG. 20 is a diagram illustrating a fifth recovery operation of the failed drive.
  • FIG. 21 is a diagram illustrating a first redundancy recovery operation when a failure occurs again in the recovery drive.
  • FIG. 22 is a diagram showing a second redundancy recovery operation at the time of failure recurrence in the recovery drive.
  • FIG. 23 is a diagram showing a third redundancy recovery operation at the time of failure recurrence in the recovery drive.
  • management table various types of information may be described using an expression such as “management table”, but the various types of information may be expressed using a data structure other than a table. Further, the “management table” can be referred to as “management information” to indicate that it does not depend on the data structure.
  • the program is executed by a processor, for example, an MP (Micro Processor) or a CPU (Central Processing Unit), and performs a predetermined process.
  • a processor for example, an MP (Micro Processor) or a CPU (Central Processing Unit)
  • the subject of processing may be a processor because the storage resource (for example, a memory) and a communication interface device (for example, a communication port) are used as appropriate.
  • the processor may have dedicated hardware in addition to the CPU.
  • the computer program may be installed on each computer from a program source.
  • the program source may be provided by, for example, a program distribution server or a storage medium.
  • each element for example, a storage device can be identified by a number or the like, but other types of identification information such as a name may be used as long as it is identifiable information.
  • identification information such as a name
  • the same reference numerals are given to the same parts, but the present invention is not limited to the present embodiment, and any application examples that meet the idea of the present invention are technical. Included in the range. Further, unless specifically limited, each component may be plural or singular.
  • FIG. 1 is a diagram illustrating the concept of the present invention.
  • a data drive such as an HDD
  • a failure hereinafter referred to as a failed drive or a blocked drive
  • data is reproduced by a correction copy process and stored in a spare drive (S101).
  • the maintenance staff replaces the failed drive with a normal drive (S103).
  • the collection copy process is a process for restoring a normal RAID configuration by generating data of a failed drive from a plurality of other normal drives constituting a RAID group and storing the data in another normal drive. It is.
  • the copy back process is a process of copying the data of the spare drive to the replaced normal drive after recovery or replacement of the failed drive, and restoring the normal RAID configuration with only the normal drive.
  • the normal RAID group is restarted only with the normal drive (S105).
  • SATA Serial ATA
  • 3 TB Transmission Bytes
  • the required time from drive blockage due to the above failure to normal operation is about 12 to 13 hours for collection copy processing.
  • maintenance personnel must be resident in the vicinity of the storage system all day long, so maintenance was poor.
  • the copy-back process is a simple read / write copy, and the copy time can be shortened because the parity generation operation of read / parity generation / write is not required unlike the collection copy process.
  • the failed drive is automatically recovered as a normal drive by the recovery operation and the inspection process.
  • the recovery operation is an operation for removing a failure by executing one or a plurality of appropriate recovery operations for an error factor in the failed drive.
  • the inspection process is a write or read inspection performed on the recovered drive in accordance with the redundancy of the RAID configuration, the data copy time, etc., and determines whether or not the recovered drive is to be reused based on the inspection result. . Details will be described later.
  • a drive in which a temporary failure has occurred can be automatically played back and reused. This eliminates the need for drive replacement by maintenance personnel in S105, and improves the operating rate of the storage system and reduces maintenance man-hours and costs.
  • FIG. 2 is a configuration diagram of the storage system.
  • the storage system 1 of the present invention is connected to a host terminal (hereinafter referred to as a host) 2 via a LAN (Local Area Network) 3 and includes a disk controller unit 13 and a disk drive unit 14. What is configured by the disk controller unit 13 and the disk drive unit 14 may be referred to as a basic case, and the single disk drive unit 14 may be referred to as an additional case.
  • a host terminal hereinafter referred to as a host
  • LAN Local Area Network
  • the user or system administrator can increase the total storage capacity of the entire storage system 1 by connecting one or more additional chassis to the basic chassis according to the application.
  • the basic chassis and the additional chassis may be collectively referred to as a chassis.
  • a maintenance terminal 15 is connected to the storage system 1, and the maintenance terminal 15 is connected to an output device that displays the operating status and failure information of the CPU, memory, storage system 1 and drive, and a determination table (not shown). It has an input device for receiving set values and thresholds.
  • the disk controller unit 13 has one or more controller packages 131. In order to improve the reliability and processing performance of the storage system 1, two controller packages 131 are provided as shown in FIG. 2, but three or more controller packages 131 may be provided.
  • the controller package 131 includes a channel control unit 132, a cache memory 133, a data controller 134, a CPU 135, a shared memory 136, a disk control unit 137, and a local memory 138.
  • the channel control unit 132 is a controller for communicating with the host 2, and transmits / receives an IO request command from the host 2, write data to a data drive (hereinafter referred to as drive) 143, or read data from the drive 143. I do.
  • the cache memory 133 is a non-volatile memory such as a volatile memory or a flash memory, and temporarily stores user data from the host 2 or the user data stored in the drive 143 in addition to system control information such as various programs and management tables. It is a memory that holds it automatically.
  • the data controller 134 is a controller that performs transfer of an IO request command to the CPU 135, transfer of write data to the cache memory 133, and the like.
  • the CPU 135 is a processor that controls the entire storage system 1.
  • the shared memory 136 is a non-volatile memory such as a volatile memory and a flash memory, and is a memory shared by various controllers and processors, and stores system control information, control information such as various programs and management tables, and the like.
  • the disk control unit 137 is a controller that communicates between the disk controller unit 13 and the disk drive unit 14.
  • the local memory 138 is a memory for the CPU 135 to access data such as storage system control information, management information, and calculation results at high speed, and is configured by a non-volatile memory such as a volatile memory or a flash memory.
  • Programs and tables according to the present invention to be described later are stored in the local memory 138 and read out by the CPU 135 as appropriate. Note that the programs and tables in the present invention may be stored not only in the local memory 138 but also in a part of the storage area of the drive 143 or in another memory.
  • the drive unit 14 includes a plurality of expanders 141, a plurality of drives (reference numerals 143 to 146), and one or more spare drives 147.
  • Two or more drives form a RAID group 142 such as RAID 5 having a 3D + 1P configuration or RAID 6 having a 3D + 2P configuration.
  • the expander 141 is a controller for connecting more than the number of drives defined by the standard.
  • the drive 143 to the drive 146 and the spare drive 147 are connected to the disk control unit 137 of the disk controller unit 13 via the expander 141, and exchange data and commands.
  • the spare drive 147 is a spare drive used when the drive 143 to the drive 146 constituting the RAID group 142 is failed or replaced.
  • Drives 143 to 146 and spare drive 147 are FC (Fibre Channel), SAS (Serial Attached SCSI), SATA type HDD, SSD (Solid State Drive), and the like.
  • FIG. 3 is a diagram illustrating a configuration example of an error factor determination table.
  • the error factor determination table 30 is a table for determining the error factor 302 from the Sensekey / Sensecode 301.
  • Sensekey / Sensecode is error information reported to the controller and host when the drive detects an error, and is generated according to the standard.
  • Error factors 302 include Not_Ready 311, media error 312, seek error 313, hardware error 314, I / F error 315, and others 316.
  • Not_Ready 311 is an error indicating that the drive is not activated.
  • Media error 312 is an error in writing to or reading from the media, such as a CRC (Cyclic Redundancy Check) error or a compare error caused by a write failure or read failure.
  • CRC Cyclic Redundancy Check
  • the seek error 313 is a head seek error that is caused by an incorrect head position or an incapable head movement.
  • the hardware error 314 is an error classified as a hardware error other than the Not_Ready 311 to the seek error 313 and the I / F error 315.
  • the I / F error 315 is a parity error due to an error in data transfer or communication.
  • Other 316 is an error other than errors from Not_Ready 311 to I / F error 315.
  • FIG. 4 is a diagram showing a configuration example of the recovery count management table.
  • the recovery count management table 40 manages the recovery count value of each drive, and the drive location 401 that is the position information inside the storage system of the drive and the recovery that is the number of recovery operations and inspection processes executed in each drive. It consists of a count 402.
  • the drive location 401 includes a housing number that is number information of a housing that is stored and a drive number that is information of an insertion position in the housing.
  • this recovery count management table 40 the number of times of recovery operation for a failure in each drive is counted, and the number of times recovery can be executed by the recovery operation & inspection process described later (hereinafter referred to as the number of recovery times) is limited. This is because there is a high possibility that a drive with a high number of times of recovery will fail frequently, and the probability of a serious failure will be high, making it unusable. Therefore, in the present invention, by limiting the number of times of recovery, unnecessary recovery operation & inspection processing is eliminated, and the occurrence of a fatal failure is avoided.
  • FIG. 5 is a diagram illustrating a configuration example of the recovery operation determination table.
  • the recovery operation determination table 50 is a table for determining the recovery operation 502 to be performed on the failed drive from the error factor 501.
  • the error factors 501 are from the above Not_Ready 311 to the other 316.
  • the type of the recovery operation 502 is that a part of or all of the semiconductor chips (CPU, drive interface controller, etc.) constituting the electronic circuit of the drive main body are turned into hardware by turning off the power supply of the drive main body and then turning it on.
  • An innermost / outermost seek 515 that moves from the outermost periphery to the innermost periphery, and a random write / read 516 that randomly writes and reads data.
  • the error factor 501 is an I / F error
  • the power ON / OFF 511 and the hard reset 512 are executed, but the other formats 514 and the innermost / outermost seek 515 are not executed. This is for shortening the recovery time by omitting the recovery operation at a site not related to the fault occurrence site.
  • the recovery operation 502 with a circle (O) for each error of the error cause 501 is performed on the failed drive in order from the top.
  • the recovery operation can be recovered from the upper recovery operation, so the recovery operation is performed in order from the top.
  • an intermediate recovery operation for example, a media error 312, it may be executed from the hardware reset 512 instead of the power ON / OFF 511.
  • FIG. 6 is a flowchart illustrating the recovery operation and the inspection process according to the first embodiment.
  • FIG. 7 is a flowchart illustrating the error factor confirmation process in the first embodiment. A description will be given assuming that the processing subject is the CPU 135 and the failed drive is the drive 146.
  • FIGS. 6 and 7 corresponds to S102 in FIG. 1.
  • the CPU 135 starts recovery operation and inspection processing.
  • the CPU 135 executes the error factor confirmation process of FIG. 7 to confirm the cause of the drive blockage.
  • step S ⁇ b> 701 the CPU 135 acquires error information from the memory 138 when it is determined that the drive constitutes the RAID group 142 is blocked.
  • the CPU 135 determines whether or not the acquired error information includes Sensekey / Sensecode. If there is a Sensekey / Sensode, the CPU 135 executes S703, and if there is no Sensekey / Sensecode content, the CPU 135 executes S704.
  • the CPU 135 determines an error factor using the error factor determination table 30 of FIG. For example, if Sensekey / Sensecode is “04H / 02H” (H is an abbreviation for Hexadecimal, and “H” may be omitted in the following description), the error factor determination result is set to seek error 313.
  • the CPU 135 sets “other” as the error factor determination result. After determining the error factor, the CPU 135 returns the process to S601 and executes the subsequent processes after S602.
  • the determination of the error factor may be made using not only error information at the time of determining as a blockage but also error statistical information up to the blockage. For example, even if the error information at the time of determining as blockage is the seek error 313, but the I / F error 315 has also occurred in the error statistical information, the error cause determination result is both the seek error 313 and the I / F error 315. And
  • the CPU 135 checks the recovery count of the failed drive 146 in the recovery count management table 40, and determines whether the recovery count is equal to or greater than a preset threshold value n1. For example, the recovery count 402 whose drive location 401 is “00/01” is “2”, and it is determined whether or not this is greater than or equal to the threshold value n1. If it is above (Yes in S602), the CPU 135 determines that the recovery operation and the inspection process cannot be executed ("NG").
  • drive replacement (S103) is performed as shown in FIG. If the recovery count is less than the threshold value n1 (“Yes”), the CPU 135 determines that the recovery operation and the inspection process can be executed.
  • the CPU 135 performs a recovery operation based on the error factor. That is, the error factor is checked against the recovery operation determination table 50 and an appropriate recovery operation 502 is selected. For example, in the case of a seek error 313, the CPU 153 performs one or more of a hard reset 512, a media / head motor stop / start 513, and an innermost / outermost seek 514 as a recovery operation 502 with respect to the failed drive. Execute and determine whether to recover. If the error factor determination result in the error factor confirmation processing is both the seek error 313 and the I / F error 315 as described above, one or more recovery operations or two or more recovery operations from the recovery operation 502 in both errors. A recovery operation combining the above is executed.
  • the CPU 135 executes S604. If not recovered, the CPU 135 determines that recovery is not possible ("NG"), ends the recovery operation and inspection processing, and makes a request for drive replacement (S103).
  • NG recovery is not possible
  • the CPU 135 performs a write / read inspection on the entire medium of the drive.
  • This inspection by writing / reading includes the above-described CRC check or a comparison check between write data and read data.
  • the CPU 135 determines whether the number of error occurrences during the inspection is equal to or less than the error threshold value m1.
  • the error threshold value m1 is equal to or less than the threshold value during normal system operation. The reason is that a drive that has been recovered from a failure is likely to fail again, so that a strict inspection that exceeds the normal inspection is performed to confirm the reliability of the recovered drive. If the number of errors that occurred during the inspection exceeds the error threshold value m1, the CPU 135 determines that recovery is not possible (“NG”). If the error threshold value m1 or less, the CPU 135 determines that the failed drive has been successfully recovered (“Pass”).
  • the CPU 135 increments the recovery count of the drive recovered from the failure by one and updates the recovery count management table 40. Then, the CPU 135 returns the process to S102 of FIG. Then, the CPU 135 executes the processing from S104 onward, and puts the storage system 1 into a normal operation state.
  • a drive in which a temporary failure has occurred can be automatically recovered and recovered for reuse. Therefore, it is unnecessary to replace the drive by maintenance personnel, and it is possible to improve the operating rate of the storage system and reduce maintenance man-hours and costs.
  • FIG. 8 is a diagram illustrating a first recovery operation of the failed drive.
  • the first recovery operation is performed when dynamic sparing is successful before the drive is blocked, and recovers data from the spare drive by copyback processing after successful recovery of the failed drive or after drive replacement. It is.
  • This dynamic sparing function automatically saves the data of degraded drives (drives that are highly likely to cause a fatal failure) online to the spare drive by threshold management of the internal retry count in each drive. It is a function.
  • the CPU 135 uses the dynamic sparing 81 to copy and save the degraded data of the drive 146 to the spare drive 147.
  • the CPU 135 performs recovery operation and inspection processing on the blocked drive 146 to recover the drive 146.
  • the CPU 135 copies and recovers data from the spare drive 147 to the drive 146 in the copy back processing 82 after the recovery of the blocked drive 146 is successful.
  • the CPU 135 restores the RAID group 142 from the drive 143 to the drive 146 after the completion of data recovery from the spare drive 147 to the drive 146 by the copy back process, and returns the storage system 1 to the normal operation state.
  • the recovery operation and the inspection process shown in the flowcharts of FIGS. 6 and 7 can be executed to automatically recover the failed disk. Therefore, it is possible to improve the operating rate of the storage system 1 and reduce maintenance man-hours.
  • FIG. 9 is a diagram illustrating a second recovery operation of the failed drive.
  • the second recovery operation is an operation that is executed when data construction to the spare drive 147 by dynamic sparing cannot be completed before the drive is blocked.
  • data collection is executed for the spare drive 147 in the collection copy process 83, the recovery of the failed drive 146 is successful, and data construction is completed in the spare drive 147, the data is recovered in the copy back process 82. To do.
  • the CPU 135 performs recovery operation and inspection processing on the blocked drive 146 to recover the drive 146.
  • the CPU 135 copies the data from the spare drive 147 to the drive 146 restored in (2) in the copy back processing 82 after the data construction to the spare drive 147 is completed, and recovers the data in the drive 146. Execute.
  • the CPU 135 restores the RAID group 142 from the drive 143 to the drive 146 after the data recovery from the spare drive 147 to the drive 146 by the copy back process, and returns the storage system 1 to the normal operation state. .
  • the second recovery operation can automatically regenerate and reuse a drive in which a temporary failure has occurred, improving the operation rate of the storage system, Maintenance man-hours and costs can be reduced.
  • the strictness of the required inspection and the importance of recovery without replacement are different. For example, it is necessary to change the inspection contents and inspection time depending on whether redundancy is maintained even when one drive is blocked. For example, if the redundant configuration is a RAID 5 configuration such as 3D + 1P, the redundancy is lost if one drive fails. For this reason, it is necessary to quickly perform data construction and redundancy recovery by correction copy processing to the spare drive. Therefore, the type of recovery operation for the generated error is limited, simple inspection is selected, and early drive replacement is performed.
  • the inspection content and the inspection time can be made variable depending on the redundancy, the copy time, and the number of executed recoveries.
  • FIG. 10 is a diagram illustrating a configuration example of the maximum recovery number determination table.
  • the maximum recovery number determination table 100 determines the maximum number of times that a recovery operation can be executed based on redundancy and copy time.
  • the maximum recovery number determination table 100 has a redundancy 1001, a copy time 1002, and a threshold value n2 of a reference numeral 1003.
  • Redundancy 1001 indicates whether there is redundancy in the RAID configuration when a failure occurs. That is, as described above, when one storage device constituting a RAID group is blocked, the redundancy 1001 is “none” in RAID 5 (3D + 1P), but the redundancy 1001 is “present” in RAID 6 (3D + 2P). Become.
  • the copy time 1002 is an average of the entire copy time measured for each type of drive. For example, if the copy time is within 24 hours, the copy time 1002 is determined to be “small”, and if it is 24 hours or longer, it is determined to be “large”. In this example, classification is made in two levels, “large” and “small”, but it may be classified in three levels, “large”, “medium”, and “small”.
  • the threshold n2 1003 is increased to increase the number of times the recovery operation and the inspection process can be executed. Conversely, if the redundancy 1001 is “None” and the copy time 1002 is “Large”, the threshold value n2 1003 is decreased. This is because when there is redundancy and the copy time is short, the fault tolerance is sufficient, so that the number of executions of the recovery operation can be increased.
  • FIG. 11 is a diagram illustrating a configuration example of the examination content determination table.
  • the inspection content determination table 110 is a table for determining the inspection content according to the situation when a failure occurs in the drive.
  • the inspection content determination table 110 includes redundancy 1101, copy time 1102, write command error flag 1103, and inspection content 1104.
  • the redundancy 1101 and the copy time 1102 are the same as the redundancy 1001 and the copy time 1002 described above.
  • the write command error flag 1103 is a flag that indicates whether a failure has occurred during execution of a write command from the host 2 and is blocked. This is because a check by writing is always incorporated into the inspection if an error has occurred in the write command at the time of blocking.
  • the inspection content 1104 indicates the inspection content for the drive with the failure, and an appropriate inspection content is selected based on the redundancy 1101, the copy time 1102, and the write command error flag 1103. For example, if there is redundancy and the copy time is short, the fault tolerance and time are sufficient, so “full write / read”, which is a careful inspection, is performed. In addition, depending on the copy time and redundancy, the type, number, and combination of recovery operations executed in the recovery operation as well as the inspection contents may be changed.
  • the data used for the inspection may be specific pattern data or user data.
  • FIG. 12 is a diagram illustrating a configuration example of the error threshold determination table.
  • the error threshold determination table 120 determines a recovery reference for a failed drive based on the number of times the recovery operation is performed, and sets a threshold for each error according to the recovery count number. That is, when the recovery operation is executed many times, the inspection result is judged more strictly.
  • the error threshold determination table 120 has a recovery count 1201 and error content 1202. As the recovery count 1201 increases, the number of error occurrences allowed in the inspection is reduced. For example, when the error content 1202 is “media error”, as the recovery count 1201 increases to 0, 1, 2, 3, the number of error occurrences allowed in the inspection decreases to 5, 3, 1, 0. We will continue to conduct strict inspections.
  • a recovered error is an error that has been remedied by a retry process inside the drive, and access by a write command or a read command has succeeded.
  • FIG. 13 is a flowchart illustrating the recovery operation and the inspection process according to the second embodiment.
  • FIG. 14 is a flowchart illustrating error factor confirmation processing according to the second embodiment. A description will be given assuming that the processing subject is the CPU 135 and the failed drive is the drive 146.
  • the CPU 135 executes error factor confirmation processing (FIG. 14).
  • the CPU 135 obtains error information from the memory 138 when the blockage determination is made.
  • the CPU 135 determines whether there is an error during execution of the write command based on the acquired error information. If it is an error during the execution of the write command (Yes in S1402), the CPU 135 executes S1404.
  • the CPU 135 sets the write command error flag to “0”. In S1404, the CPU 135 sets the write command error flag to “1”.
  • step S1405 the CPU 135 determines whether there is a Sensekey / Sensecode. If yes (Yes in S1405), the CPU 135 executes S1406. If not, the CPU 135 executes S1407.
  • the CPU 135 determines an error factor using the error factor determination table 30 (FIG. 3).
  • the CPU 135 predicts the copy time from the specification of the failed drive (total storage capacity, rotation speed, average seek time, access speed, etc.), and determines the size of the copy time.
  • the CPU 135 determines redundancy. For example, if the RAID group including the failed drive is a RAID 5 configuration, it is determined as “No”, and if it is a RAID 6 configuration, it is determined as “Yes”.
  • the CPU 135 confirms the recovery count of the failed drive 146 in the recovery count management table 40, and determines whether or not the threshold is n2 or more. If the threshold value is greater than or equal to the threshold value n2 (Yes in S1304), the CPU 135 determines that the failed drive cannot be recovered and prompts the maintenance personnel to replace the drive in S103 of FIG. When the threshold value is not equal to or greater than n2 (No in S1304), the CPU 135 executes S1305.
  • the CPU 135 selects a recovery operation based on the error factor from the recovery operation determination table 50 and sequentially executes the failure drive. If recovered, the CPU 135 executes S604. If not recovered, the CPU 135 determines that recovery is not possible ("NG"), ends the recovery operation and inspection processing, and makes a request for drive replacement (S103).
  • NG recovery is not possible
  • the CPU 135 determines the inspection contents to be executed by checking the inspection according to the situation, that is, the status of the redundancy, the copy time, and the write command error flag against the inspection content determination table 110.
  • step S1307 the CPU 135 compares the number of errors generated as a result of the inspection with the error threshold in the error threshold determination table 120. For example, if the drive 146 is blocked due to a media error and the recovery count 1201 of the failed drive 146 is “1”, the media error that occurred at the time of inspection is up to 3 times, the recovered error is up to 100 times, and the hard error If it is up to once and other errors are up to once, the recovered drive is judged to be usable ("Pass”) and reused. On the contrary, when one error item exceeds the threshold value or all error items exceed the threshold value, it is determined that reuse is not possible ("NG").
  • the CPU 135 increments the recovery count value of the drive (recovery drive 146) by one, and updates the contents of the recovery count management table 40 with the value.
  • a drive in which a temporary failure has occurred can be automatically regenerated and reused, and the operation rate of the storage system can be improved. Can be reduced.
  • FIG. 15 is a diagram illustrating a configuration example of a data recovery area management table in a failed drive.
  • FIG. 16 is a diagram illustrating a configuration example of a data recovery area management table in the spare drive.
  • the data recovery area management table 150 (hereinafter referred to as the data recovery area management table 150) for the failed drive and the data recovery area management table 160 (hereinafter referred to as the data recovery area management table 160) for the spare drive are being recovered (see FIG.
  • the data range written to the spare drive 147 is managed during the recovery operation & inspection process). After the recovery of the failed drive 146, data is reconstructed using this management table.
  • the data recovery area management table 150 includes a drive location 1501 indicating the mounting position of the failed drive 146, a recovery required address 1502 indicating the written data range, and a data writing factor 1503.
  • the recovery required address 1502 includes a write start position 15021 and a write end position 15022.
  • the data write factor 1503 distinguishes between data write by the write I / O from the host 2 and data write at the time of inspection.
  • the data recovery area management table 160 has a spare drive location 1601 indicating the mounting position of the spare drive 147, a drive location 1602 indicating the mounting position of the failed drive 146, and a recovery required address 1603 indicating the written data range.
  • the required address 1603 includes a write start position 16031 and a write end position 16032.
  • FIG. 17 is a diagram illustrating a third recovery operation of the failed drive. This third recovery operation starts data construction in the recovery drive 146 even before the collection copy process 83 is completed.
  • the collection copy destination is immediately changed from the spare drive 146 to the recovery drive 146 without waiting for the completion of the correction copy process 83, and data recovery is performed for data other than the data constructed area 147a written in the spare drive. I do.
  • the remaining data is restored to the drive 146 from the spare drive 147 by the copy back processing 82 this time.
  • data recovery to the recovery drive 146 is performed in a short time.
  • the CPU 135 constructs data in the spare drive 147 in the collection copy process 83.
  • the CPU 135 stores a pointer 85 indicating the data constructed area 147a of the spare drive 147 before drive recovery by the recovery operation & inspection processing.
  • FIG. 18 is a diagram illustrating the data and parity update operation in the fourth recovery operation of the failed drive.
  • FIG. 19 is a diagram showing data recovery processing in the fourth recovery operation of the failed drive. In the fourth recovery operation, data recovery of the recovery drive is performed using user data originally stored in the drive.
  • the blocked drive that was originally a data drive is recovered and used, the correct data is originally stored in the drive, and the data recovery can be completed at an early stage by updating only the data in the following area. .
  • the CPU 135 manages the data constructed area 147a of the spare drive 147 with pointers 86a to 86e (sometimes collectively referred to as 86).
  • pointers 86a to 86e sometimes collectively referred to as 86.
  • the addresses (a) to (c) c are first stored as “addresses requiring recovery” in the data recovery area management table 150. Then, the true “address that needs to be recovered” is specified from the pointer 86 at the time of recovery of the failed drive 146.
  • the CPU 135 When updating data in the spare drive data constructed area 147a
  • the CPU 135 registers in the data recovery area management table 150 where the address was overwritten, and overwrites the spare drive 147 with data.
  • the CPU 135 generates parity data using the host I / O data and the remaining two drives 144 and 145 and overwrites the parity drive 143.
  • the CPU 135 recovers the failed drive 146 by the recovery operation & inspection process. If it can be recovered, the CPU 135 determines whether the inspection process can be performed and reused. When it is determined that the data can be reused, the CPU 135 executes the following data recovery operation.
  • (2-1) Data recovery operation 1 The CPU 135 refers to the data recovery area management table 150. If the data overwrite cause 1503 is due to “host I / O” and the data at the recovery required address 1502 is in the data constructed area 147a of the spare drive 147, copy back In step 82, data recovery to the recovery drive 146 is executed.
  • the CPU 135 refers to the data recovery area management table 150, the data overwrite factor 1503 is due to “host I / O”, and the data at the recovery required address is not in the data constructed area 147a of the spare drive 147 but in the area 147b.
  • data recovery is executed. Further, the data recovery is executed in the correction copy process 83 for the area of the address requiring recovery when the data overwrite factor 1503 is “inspection”.
  • the CPU 135 restores the RAID group 142 from the drive 143 to the drive 146 after the completion of data recovery to the drive 146 by the copy back process 82 or the collection copy process 83, and stores the data.
  • the system 1 is returned to the normal operating state.
  • the failed drive can be automatically reproduced and reused.
  • the RAID group 142 can be restored only by copying only the data in the updated area to the restored drive, the recovery time from the failure can be shortened.
  • FIG. 20 is a diagram showing a fifth recovery operation of the failed drive.
  • the recovery operation and the inspection process are performed using the user data as they are.
  • (1) Data recovery operation 1 In the data recovery operation 1, the update data to the data construction area 147a of the spare drive 147 is reflected on the drive 146 to be recovered. Therefore, the CPU 135 uses the data of the spare drive 147 and overwrites the data at the same address as the recovery target drive 146 by copy back processing.
  • the failed drive can be automatically reproduced and reused.
  • the failed drive can be automatically regenerated and reused, and the operation rate of the storage system can be improved and maintenance man-hours and costs can be reduced.
  • the reliability of the storage system can be improved by selecting appropriate inspection contents according to the failure occurrence status and pursuing the strictness of the inspection based on the recovery history of the failed drive.
  • FIG. 21 is a diagram illustrating a first redundancy recovery operation when a failure occurs again in the recovery drive.
  • the spare drive 147 stores all the same data as the recovery drive 146. Even when the recovery operation by the recovery operation and the inspection process is completed, the spare drive 147 is not released immediately, but is used in parallel with the recovered drive 146, thereby realizing quick redundancy recovery at the time of re-blocking. is there.
  • the CPU 135 restores the RAID group 142 from the drive 143 to the drive 146 after the completion of data recovery from the spare drive 147 to the drive 146 by the copy back process 82 or the collection copy process 83, and returns to the normal operation state.
  • the storage system 1 is restored. Thereafter, the CPU 135 continues to use the spare drive 147 as a drive for early recovery of redundancy.
  • FIG. 22 is a diagram showing a second redundancy recovery operation at the time of failure recurrence in the recovery drive.
  • the write area is recorded and the data of the spare drive 147 is updated when it becomes necessary.
  • the data difference between the recovery drive 146 and the spare drive 147 is registered in the data recovery area management table 160.
  • the recovery drive 146 is re-occluded within a short time, the area registered in the data recovery area management table 160 is reflected in the spare drive 147 to recover the redundancy.
  • FIG. 23 is a diagram showing a third redundancy recovery operation at the time of failure recurrence in the recovery drive.
  • the data constructed area 147a of the spare drive 147 (area reflecting the data of the recovery drive 146) is a pointer in the redundancy recovery operation to be executed. Manage with. Then, at the time of write I / O from the host 2 to the data constructed area 147a, it is recorded in both the recovery drive 146 and the spare drive 147. At the time of re-occlusion, data is constructed by the collection copy process 83 using the drive 143/144/145 in the data unconstructed area 147b of the spare drive 147.
  • the CPU 135 manages the boundary between the data construction area 147a and the data non-construction area 147b, which are valid data areas in the spare drive 147, with the pointer 89.
  • the drive 143/144/145 and the spare drive 147 constitute a RAID group by switching to use as a data drive, Restore redundancy.
  • the recovery time of redundancy can be shortened by constructing data only in the area having no valid data in the spare drive 147 by the collection copy process 83. .
  • the predetermined time may be set in the storage system 1 in advance, or a value received from the input device of the maintenance terminal 15 may be used.
  • the RAID group can be quickly recovered, and the reliability and operating rate of the storage system can be improved.
  • this invention is not limited to the above-mentioned Example, Various modifications are included.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described. Further, 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. Further, it is possible to add, delete, and replace other configurations for a part of the configuration of each embodiment.
  • 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 interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files for realizing each function may be stored in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.
  • a recording device such as an SSD (Solid State Drive)
  • a recording medium such as an IC card, an SD card, or 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 (14)

  1. 　ホスト計算機に接続するストレージシステムであって、
    　前記ストレージシステムは、
    　コントローラと、
    　メモリと、
    　前記ホスト計算機からのデータを格納する複数のデータ記憶デバイスと、
    　前記データ記憶デバイスの代替として使用する１つ以上のスペア記憶デバイスとを
    備え、
    　前記データ記憶デバイスを２つ以上でＲＡＩＤグループを構成し、
    　前記コントローラは、
    　前記データ記憶デバイスが障害で閉塞すると判断した時、
    　　前記データ記憶デバイスが未閉塞状態では、前記データ記憶デバイスのデータを直接前記スペア記憶デバイスへ格納し、
    　　前記データ記憶デバイスが閉塞状態では、前記ＲＡＩＤグループを構成する正常なデータ記憶デバイスからデータを再生して前記スペア記憶デバイスに格納し、
    　前記閉塞状態のデータ記憶デバイスに対し、障害内容に対応した障害回復処理及び所定の検査処理を実行する
    　ことを特徴とするストレージシステム。
     
  2. 　請求項１記載のストレージシステムであって、
    　前記障害は、前記データ記憶デバイスでの
    　（１）起動障害
    　（２）記憶媒体へのアクセス障害
    　（３）シーク動作障害
    　（４）ハードウェア動作障害
    　（５）インタフェースアクセス障害
    のいずれかである
    　ことを特徴とするストレージシステム。
     
  3. 　請求項１記載のストレージシステムであって、
    　前記障害回復処理は、前記データ記憶デバイスに対する
    　（ａ１）電源ＯＦＦ／ＯＮ動作
    　（ａ２）ハードリセット動作
    　（ａ３）モータ停止と再始動動作
    　（ａ４）記憶領域の初期化動作
    　（ａ５）記憶領域の読み取り部の移動動作
    　（ａ６）記憶領域への書き込み／読み出し動作
    　で、
    　前記コントローラが前記（ａ１）から（ａ６）の動作を１つ以上実行する
    　ことを特徴とするストレージシステム。
     
  4. 　請求項１記載のストレージシステムであって、
    　前記検査処理は、
    　（ｂ１）記憶領域全体のデータ読み出し
    　（ｂ２）記憶領域全体のデータ書き込み
    　（ｂ３）記憶領域全体のデータ書き込み及びデータ読み出し
    　（ｂ４）所定時間の記憶領域へのデータ読み出し
    　（ｂ５）所定時間の記憶領域へのデータ書き込み
    　（ｂ６）所定時間の記憶領域へのデータ書き込み及びデータ読み出し
    　（ｂ７）記憶領域全体のデータ書き込み及びデータ読み出しと、書き込みデータと読み出しデータとの比較
    　（ｂ８）所定時間の記憶領域へのデータ書き込み及びデータ読み出しと、書き込みデータと読み出しデータとの比較
    　のいずれかである
    　ことを特徴とするストレージシステム。
     
  5. 　請求項１記載のストレージシステムであって、
    　前記コントローラは、
    　前記回復処理及び検査処理を実行した回復・検査回数を前記データ記憶デバイス毎に管理する
    　ことを特徴とするストレージシステム。
     
  6. 　請求項５記載のストレージシステムであって、
    　前記コントローラは、
    　前記回復・検査回数が予め設定された閾値を超える場合には、前記回復処理及び検査処理を実行しない
    　ことを特徴とするストレージシステム。
     
  7. 　請求項１記載のストレージシステムであって、
    　前記コントローラは、
    　障害発生時の冗長性の有無と、
    　前記障害が発生したデータ記憶デバイスの全記憶データの前記スペア記憶デバイスへの格納時間とにより、
    　前記障害回復処理または検査処理の実行を決定する
    　ことを特徴とするストレージシステム。
     
  8. 　請求項７記載のストレージシステムであって、
    　前記コントローラは、
    　前記障害発生が前記ホスト計算機からのＩＯアクセスに起因する場合、
    　前記冗長性の有無、前記格納時間、前記ＩＯアクセス種別のいずれか２つ以上の組み合わせで、前記検査処理の種類を決定する
    　ことを特徴とするストレージシステム。
     
  9. 　請求項１記載のストレージシステムであって、
    　前記コントローラは、
    　前記回復処理及び検査処理を実行した回復・検査回数を前記データ記憶デバイス毎に管理し、
    　前記回復・検査回数に応じて、前記検査処理で障害種別毎の障害許容数を決定し、
    　前記検査処理で発生した障害発生数が、前記障害許容数を下回る場合は、前記閉塞状態のデータ記憶デバイスの閉塞を解除する
    　ことを特徴とするストレージシステム。
     
  10. 　請求項１記載のストレージシステムであって、
    　前記障害が発生したデータ記憶デバイスが、障害回復処理及び検査処理で復旧した時、　　
    　前記コントローラは、
    　前記再生データの格納先を前記スペア記憶デバイスから前記復旧したデータ記憶デバイスに切り替え、
    　前記スペア記憶デバイスへ格納済みデータを前記復旧したデータ記憶デバイスへ格納する
    　ことを特徴とするストレージシステム。
     
  11. 　請求項１記載のストレージシステムであって、
    　前記コントローラは、
    　前記回復処理または前記検査処理の実行中に、前記ホスト計算機から前記ＲＡＩＤグループを構成するデータ記憶デバイスまたは前記スペア記憶デバイスへのデータ更新要求が発生した場合、データ更新範囲を前記メモリないし前記データ記憶デバイスに格納し、
    　閉塞状態を解除されたデータ記憶デバイスに対し、前記データ更新範囲のデータを格納する
    　ことを特徴とするストレージシステム。
     
  12. 　記憶デバイス障害回復方法であって、
    　データ記憶デバイスにホスト計算機からのデータを格納し、前記データ記憶デバイスを２つ以上でＲＡＩＤグループを構成し、
    　前記データ記憶デバイスが障害で閉塞すると判断した時、
    　　前記データ記憶デバイスが未閉塞状態では、前記データ記憶デバイスのデータを直接前記スペア記憶デバイスへ格納し、
    　　前記データ記憶デバイスが閉塞状態では、前記ＲＡＩＤグループを構成する正常なデータ記憶デバイスからデータを再生して前記スペア記憶デバイスに格納し、
    　前記閉塞状態のデータ記憶デバイスに対し、障害内容に対応した障害回復処理及び所定の検査処理を実行する
    　ことを特徴とする記憶デバイス障害回復方法。
    　
  13. 　請求項１２記載の記憶デバイス障害回復方法であって、
    　前記障害回復処理は、
    　（ａ１）電源ＯＦＦ／ＯＮ
    　（ａ２）ハードリセット
    　（ａ３）モータ停止と再始動
    　（ａ４）記憶領域の初期化
    　（ａ５）記憶領域の読み取り部の移動
    　（ａ６）記憶領域への書き込み／読み出し
    　の１つ以上を選択して実行し、
    　前記検査処理は、
    　（ｂ１）記憶領域全体のデータ読み出し
    　（ｂ２）記憶領域全体のデータ書き込み
    　（ｂ３）記憶領域全体のデータ書き込み及びデータ読み出し
    　（ｂ４）所定時間の記憶領域へのデータ読み出し
    　（ｂ５）所定時間の記憶領域へのデータ書き込み
    　（ｂ６）所定時間の記憶領域へのデータ書き込み及びデータ読み出し
    　（ｂ７）記憶領域全体のデータ書き込み及びデータ読み出しと、書き込みデータと読み出しデータとの比較
    　（ｂ８）所定時間の記憶領域へのデータ書き込み及びデータ読み出しと、書き込みデータと読み出しデータとの比較
    　のいずれかを選択し実行する
    　ことを特徴とする記憶デバイス障害回復方法。
     
  14. 　ストレージシステムであって、
    　前記ストレージシステムはホスト計算機及び保守端末に接続し、
    　前記ストレージシステムは
    　コントローラと、
    　メモリと、
    　前記ホスト計算機からのデータを格納する複数のデータ記憶デバイスと、
    　前記データ記憶デバイスの代替として使用する１つ以上のスペア記憶デバイスとを
    備え、
    　前記データ記憶デバイスを２つ以上でＲＡＩＤグループを構成し、
    　前記コントローラは、
    　前記データ記憶デバイスが障害で閉塞すると判断した時、
    　　前記データ記憶デバイスが未閉塞状態では、前記データ記憶デバイスのデータを直接前記スペア記憶デバイスへ格納し、
    　　前記データ記憶デバイスが閉塞状態では、前記ＲＡＩＤグループを構成する正常なデータ記憶デバイスからデータを再生して前記スペア記憶デバイスに格納し、
    　前記閉塞状態のデータ記憶デバイスに対し、障害内容に対応した障害回復処理及び所定の検査処理を実行し、
    　前記障害回復処理は
    　（ａ１）電源ＯＦＦ／ＯＮ
    　（ａ２）ハードリセット
    　（ａ３）モータ停止と再始動
    　（ａ４）記憶領域の初期化
    　（ａ５）記憶領域の読み取り部の移動
    　（ａ６）記憶領域への書き込み／読み出し
    　で、前記コントローラが前記障害回復処理を１つ以上実行し、
    　前記検査処理は、
    　（ｂ１）記憶領域全体のデータ読み出し
    　（ｂ２）記憶領域全体のデータ書き込み
    　（ｂ３）記憶領域全体のデータ書き込み及びデータ読み出し
    　（ｂ４）所定時間内の記憶領域へのデータ読み出し
    　（ｂ５）所定時間内の記憶領域へのデータ書き込み
    　（ｂ６）所定時間内の記憶領域へのデータ書き込み及びデータ読み出し
    　（ｂ７）記憶領域全体のデータ書き込み及びデータ読み出しと、書き込みデータと読み出しデータとの比較
    　（ｂ８）所定時間内の記憶領域へのデータ書き込み及びデータ読み出しと、書き込みデータと読み出しデータとの比較
    　のいずれか１つであり、
    　前記コントローラは、
    　前記障害回復処理及び検査処理を実行した回復・検査回数を前記データ記憶デバイス毎に前記メモリに格納し、
    　前記回復・検査回数が予め設定された閾値を超える場合には、前記回復処理及び検査処理を実行せず、
    　前記冗長性の有無、前記格納時間、前記ホスト計算機からのＩＯアクセス要求の種類のいずれか２つ以上の組み合わせで、前記検査処理の種類を決定し、
    　前記コントローラは、
    　前記回復・検査回数に応じて、前記検査処理で障害種別毎の障害許容数を決定し、
    　前記検査処理で発生した障害発生数が、前記障害許容数を下回る場合は、前記閉塞状態のデータ記憶デバイスの閉塞を解除し、
    　前記障害が発生したデータ記憶デバイスが、前記障害回復処理及び前記検査処理で復旧した時、　　
    　前記コントローラは、
    　前記再生データの格納先を前記スペア記憶デバイスから前記復旧したデータ記憶デバイスに切り替え、
    　前記スペア記憶デバイスへ格納済みデータを前記復旧したデータ記憶デバイスへ格納する
    　ことを特徴とするストレージシステム。
PCT/JP2013/055282 2013-02-28 2013-02-28 ストレージシステム及び記憶デバイス障害回復方法 WO2014132373A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US14/764,397 US20150378858A1 (en) 2013-02-28 2013-02-28 Storage system and memory device fault recovery method
PCT/JP2013/055282 WO2014132373A1 (ja) 2013-02-28 2013-02-28 ストレージシステム及び記憶デバイス障害回復方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/055282 WO2014132373A1 (ja) 2013-02-28 2013-02-28 ストレージシステム及び記憶デバイス障害回復方法

Publications (1)

Publication Number Publication Date
WO2014132373A1 true WO2014132373A1 (ja) 2014-09-04

Family

ID=51427675

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/055282 WO2014132373A1 (ja) 2013-02-28 2013-02-28 ストレージシステム及び記憶デバイス障害回復方法

Country Status (2)

Country Link
US (1) US20150378858A1 (ja)
WO (1) WO2014132373A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017081748A1 (ja) * 2015-11-10 2017-05-18 株式会社日立製作所 ストレージシステム、及び、ストレージ管理方法

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6196389B2 (ja) * 2013-12-17 2017-09-13 ヒタチ データ システムズ コーポレーションＨｉｔａｃｈｉ Ｄａｔａ Ｓｙｓｔｅｍｓ Ｃｏｒｐｏｒａｔｉｏｎ 分散型ディザスタリカバリファイル同期サーバシステム
JP2016139298A (ja) * 2015-01-28 2016-08-04 京セラドキュメントソリューションズ株式会社 画像処理装置
US10983890B2 (en) * 2018-10-09 2021-04-20 Micron Technology, Inc. Real time trigger rate monitoring in a memory sub-system
US11221928B2 (en) * 2019-04-18 2022-01-11 Netapp, Inc. Methods for cache rewarming in a failover domain and devices thereof
US11321000B2 (en) * 2020-04-13 2022-05-03 Dell Products, L.P. System and method for variable sparing in RAID groups based on drive failure probability
US11640343B2 (en) 2021-05-06 2023-05-02 EMC IP Holding Company LLC Method for migrating data in a raid system having a protection pool of storage units
US20220357881A1 (en) * 2021-05-06 2022-11-10 EMC IP Holding Company LLC Method for full data recontruction in a raid system having a protection pool of storage units
US11748016B2 (en) 2021-05-06 2023-09-05 EMC IP Holding Company LLC Method for adding disks in a raid system having a protection pool of storage units
US11733922B2 (en) 2021-05-06 2023-08-22 EMC IP Holding Company LLC Method for data reconstruction in a RAID system having a protection pool of storage units
TWI820814B (zh) * 2022-07-22 2023-11-01 威聯通科技股份有限公司 儲存系統與其硬碟恢復方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006338626A (ja) * 2005-06-06 2006-12-14 Hitachi Ltd ディスクアレイ装置及びその制御方法
JP2007293448A (ja) * 2006-04-21 2007-11-08 Hitachi Ltd ストレージシステム及びその電源制御方法
JP2010224954A (ja) * 2009-03-24 2010-10-07 Toshiba Corp ストレージ装置及び論理ディスク管理方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002065309A1 (en) * 2001-02-13 2002-08-22 Candera, Inc. System and method for policy based storage provisioning and management
US7162596B2 (en) * 2002-01-11 2007-01-09 Hewlett-Packard Development Company, L.P. Remote mirrored disk pair resynchronization monitor
US6934804B2 (en) * 2002-05-28 2005-08-23 Sun Microsystems, Inc. Method and system for striping spares in a data storage system including an array of disk drives
US7076606B2 (en) * 2002-09-20 2006-07-11 Quantum Corporation Accelerated RAID with rewind capability
US7143305B2 (en) * 2003-06-25 2006-11-28 International Business Machines Corporation Using redundant spares to reduce storage device array rebuild time
JP2005100259A (ja) * 2003-09-26 2005-04-14 Hitachi Ltd ドライブの２重障害を防止するアレイ型ディスク装置、プログラム、及び方法
US20050097132A1 (en) * 2003-10-29 2005-05-05 Hewlett-Packard Development Company, L.P. Hierarchical storage system
JP4319017B2 (ja) * 2003-12-02 2009-08-26 株式会社日立製作所 ストレージシステムの制御方法、ストレージシステム、及び記憶装置
US7280353B2 (en) * 2003-12-29 2007-10-09 Sherwood Information Partners, Inc. System and method for reduced vibration interaction in a multiple-hard-disk-drive enclosure
US7360044B2 (en) * 2004-07-20 2008-04-15 Hewlett-Packard Development Company, L.P. Storage system with primary mirror shadow
US7363532B2 (en) * 2004-08-20 2008-04-22 Dell Products L.P. System and method for recovering from a drive failure in a storage array
US7529966B2 (en) * 2004-08-20 2009-05-05 Hewlett-Packard Development Company, L.P. Storage system with journaling
US20060112219A1 (en) * 2004-11-19 2006-05-25 Gaurav Chawla Functional partitioning method for providing modular data storage systems
JP5052193B2 (ja) * 2007-04-17 2012-10-17 株式会社日立製作所 記憶制御装置および記憶制御方法
GB2513377A (en) * 2013-04-25 2014-10-29 Ibm Controlling data storage in an array of storage devices

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006338626A (ja) * 2005-06-06 2006-12-14 Hitachi Ltd ディスクアレイ装置及びその制御方法
JP2007293448A (ja) * 2006-04-21 2007-11-08 Hitachi Ltd ストレージシステム及びその電源制御方法
JP2010224954A (ja) * 2009-03-24 2010-10-07 Toshiba Corp ストレージ装置及び論理ディスク管理方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017081748A1 (ja) * 2015-11-10 2017-05-18 株式会社日立製作所 ストレージシステム、及び、ストレージ管理方法
US10509700B2 (en) 2015-11-10 2019-12-17 Hitachi, Ltd. Storage system and storage management method

Also Published As

Publication number Publication date
US20150378858A1 (en) 2015-12-31

Similar Documents

Publication Publication Date Title
WO2014132373A1 (ja) ストレージシステム及び記憶デバイス障害回復方法
US8943358B2 (en) Storage system, apparatus, and method for failure recovery during unsuccessful rebuild process
US7565573B2 (en) Data-duplication control apparatus
US8713251B2 (en) Storage system, control method therefor, and program
US9600375B2 (en) Synchronized flashcopy backup restore of a RAID protected array
US8589726B2 (en) System and method for uncovering data errors
US8799745B2 (en) Storage control apparatus and error correction method
US9081697B2 (en) Storage control apparatus and storage control method
US9690651B2 (en) Controlling a redundant array of independent disks (RAID) that includes a read only flash data storage device
JPH07500203A (ja) ロールバックのためのデータ・バックアップ・システム
JP2004038290A (ja) 情報処理システムおよび同システムで用いられるディスク制御方法
US10503620B1 (en) Parity log with delta bitmap
US7653831B2 (en) Storage system and data guarantee method
JP2002049511A (ja) アドレスの割付変更方法及びこれを用いた外部記憶サブシステム
US11321178B1 (en) Automated recovery from raid double failure
EP2912555B1 (en) Hard drive backup
JP4905510B2 (ja) ストレージ制御装置及びストレージ装置のデータ回復方法
WO2021088367A1 (zh) 数据恢复方法及相关设备
US9170750B2 (en) Storage apparatus and data copy control method
US10664346B2 (en) Parity log with by-pass
JP6957845B2 (ja) ストレージ制御装置及びストレージ装置
TWI416319B (zh) 使用獨立磁碟備援陣列之電腦系統的開機方法
US11953985B1 (en) Dial-home and template based automatic recovery of virtual machine guest operating system
JP2008305213A (ja) ストレージに関する方法、製品、装置、システム
US20220413981A1 (en) Storage system

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: 13876260

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14764397

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13876260

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP