Disk array including plural exchangeable magnetic disk unit

0001This application is a continuation application of U.S. application Ser. No. 10/978,460, filed Nov.2, 2004 now U.S. Pat. No. 7,441,143, now allowed, which is a continuation application of U.S. application Ser. No. 10/860,498, filed Jun. 4, 2004, now U.S. Pat. No. 7,249,277, the entirety of which are incorporated herein by reference.

CLAIM OF PRIORITY

0002The present application claims priority from Japanese application P2004-68348 filed on Mar. 11, 2004, the content of which is hereby incorporated by reference into this application.

BACKGROUND

0003The present invention relates to a storage apparatus implementing a RAID configuration. In particular, a disk array apparatus in which a plurality of units, each of which includes a plurality of drives, are mounted.

0004In order to achieve space saving and high density mounting of drives, there has been proposed a disk array apparatus in which a plurality of units (disk blades), each of which includes a plurality of physical drives, are mounted (refer to JP 09-016343 A).

SUMMARY

0005In the above-mentioned conventional disk array apparatus, the plurality of drives in each of the units are made to appear to be a single drive. However, because each of the units is treated as the signal drive in such a structure, a plurality of RAID groups cannot be constructed on each of the units, raising a problem of low flexibility in the structure.

0006Further, it is technically possible to construct a plurality of RAID groups on each of the units. However, it is not considered to manage a relationship between a unit and a drive in the unit. When a unit in which a fault occurs is exchanged for another unit, it cannot be expected how the exchange affects other RAID groups, so that maintenance and exchange of the unit are difficult.

0007An object of the present invention is to provide a storage apparatus in which a plurality of drives in a unit are separately treated and the unit can be easily exchanged for another unit even when RAID groups are freely composed.

0008According to the present invention, a storage apparatus comprises a plurality of drive cases in each of which a plurality of units are detachably mounted, each of the units including a plurality of drives that are detachably attachable, and a controller case in which a disk control unit is provided, wherein the disk control unit comprises a RAID group creation unit for creating a RAID group using the plurality of disks and an exchangeability indicating unit for giving a notice that a unit is ready to exchange after rebuilding or copying of data in disks included in the unit at the time of exchange of the unit.

0009According to the present invention, a plurality of physical drives included in a unit can be separately treated to freely configure a RAID group. In addition, detachment and exchange on each of the unit are facilitated.

BRIEF DESCRIPTION OF THE DRAWINGS

0010<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram showing a structure of a disk array apparatus according to a first embodiment of the present invention.

0011<figref idref="DRAWINGS">FIG. 2</figref> is an external view showing the structure of the disk array apparatus according to the first embodiment of the present invention.

0012<figref idref="DRAWINGS">FIG. 3</figref> is a perspective view showing a drive case composing the disk array apparatus according to the first embodiment of the present invention.

0013<figref idref="DRAWINGS">FIG. 4</figref> is a structural view showing a disk blade composing the disk array apparatus according to the first embodiment of the present invention.

0014<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram showing a structure of a disk array controller according to the first embodiment of the present invention.

0015<figref idref="DRAWINGS">FIG. 6</figref> is an explanatory diagram showing a control program according to the first embodiment of the present invention.

0016<figref idref="DRAWINGS">FIG. 7</figref> is an explanatory diagram showing a RAID configuration according to the first embodiment of the present invention.

0017<figref idref="DRAWINGS">FIG. 8</figref> is an explanatory diagram showing a drive setting content holding table according to the first embodiment of the present invention.

0018<figref idref="DRAWINGS">FIG. 9</figref> is an explanatory diagram showing a drive state management table according to the first embodiment of the present invention.

0019<figref idref="DRAWINGS">FIG. 10</figref> is an explanatory diagram showing a RAID group state management table according to the first embodiment of the present invention.

0020<figref idref="DRAWINGS">FIG. 11</figref> is an explanatory diagram showing a background processing number management table according to the first embodiment of the present invention.

0021<figref idref="DRAWINGS">FIG. 12</figref> is an explanatory view showing a RAID group management screen displayed on a management terminal according to the first embodiment of the present invention.

0022<figref idref="DRAWINGS">FIG. 13</figref> is a flow chart showing RAID group creation processing according to the first embodiment of the present invention.

0023<figref idref="DRAWINGS">FIG. 14</figref> is a flow chart showing unit exchange processing according to the first embodiment of the present invention.

0024<figref idref="DRAWINGS">FIG. 15</figref> is a flow chart showing data rebuilding processing to a RAID group according to the first embodiment of the present invention.

0025<figref idref="DRAWINGS">FIG. 16</figref> is a flow chart showing data copying processing for a drive according to the first embodiment of the present invention.

0026<figref idref="DRAWINGS">FIG. 17</figref> is a flow chart showing exchangeable unit inserting processing according to the first embodiment of the present invention.

0027<figref idref="DRAWINGS">FIG. 18</figref> is an explanatory diagram showing the drive state management table (before occurrence of fault) according to the first embodiment of the present invention.

0028<figref idref="DRAWINGS">FIG. 19</figref> is an explanatory diagram showing the drive state management table (during data rebuilding) according to the first embodiment of the present invention.

0029<figref idref="DRAWINGS">FIG. 20</figref> is an explanatory diagram showing the drive state management table (after data rebuilding) according to the first embodiment of the present invention.

0030<figref idref="DRAWINGS">FIG. 21</figref> is an explanatory diagram showing the drive state management table (during data copying) according to the first embodiment of the present invention.

0031<figref idref="DRAWINGS">FIG. 22</figref> is an explanatory diagram showing the drive state management table (after data refuging) according to the first embodiment of the present invention.

0032<figref idref="DRAWINGS">FIG. 23</figref> is an explanatory diagram showing the drive state management table (during data copying) according to the first embodiment of the present invention.

0033<figref idref="DRAWINGS">FIG. 24</figref> is an explanatory diagram showing the drive state management table (after data refuging) according to the first embodiment of the present invention.

0034<figref idref="DRAWINGS">FIG. 25</figref> is an explanatory diagram showing the drive state management table (during refuging processing) according to the first embodiment of the present invention.

0035<figref idref="DRAWINGS">FIG. 26</figref> is an explanatory diagram showing the drive state management table (after completion of unit exchange processing) according to the first embodiment of the present invention.

0036<figref idref="DRAWINGS">FIG. 27</figref> is an explanatory diagram showing the drive state management table (after unit changing) according to the first embodiment of the present invention.

0037<figref idref="DRAWINGS">FIG. 28</figref> is an explanatory diagram showing the drive state management table (during data rebuilding) according to the first embodiment of the present invention.

0038<figref idref="DRAWINGS">FIG. 29</figref> is an explanatory diagram showing the drive state management table (after data rebuilding) according to the first embodiment of the present invention.

0039<figref idref="DRAWINGS">FIG. 30</figref> is an explanatory diagram showing a RAID group state management table according to a second embodiment of the present invention.

0040<figref idref="DRAWINGS">FIGS. 31A and 31B</figref> are explanatory views showing a RAID group management screen according to the second embodiment of the present invention.

0041<figref idref="DRAWINGS">FIG. 32</figref> is a flow chart showing guaranteed redundancy setting processing according to the second embodiment of the present invention.

0042<figref idref="DRAWINGS">FIG. 33</figref> is a flow chart showing RAID group creation processing according to the second embodiment of the present invention.

0043<figref idref="DRAWINGS">FIG. 34</figref> is a flow chart showing unit exchange processing according to the second embodiment of the present invention.

0044<figref idref="DRAWINGS">FIG. 35</figref> is an explanatory view showing a RAID group management screen according to a third embodiment of the present invention.

0045<figref idref="DRAWINGS">FIG. 36</figref> is a flow chart showing urgent maintenance notice determination processing according to the third embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0046Embodiments of the present invention will be described below with reference to the accompanying drawings.

First Embodiment

0047<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram showing a structure of a disk array apparatus according to a first embodiment of the present invention.

0048A disk array apparatus <b>1</b> according to the first embodiment of the present invention has a plurality of drive cases <b>10</b><i>a </i>and <b>10</b><i>b </i>and a controller case <b>19</b>. The disk array apparatus <b>1</b> is connected with a management terminal <b>2</b> through a management LAN <b>5</b>. In addition, the disk array apparatus <b>1</b> is connected with a plurality of SAN hosts <b>3</b> through a SAN <b>4</b>.

0049A plurality of units (disk blades) <b>101</b>, <b>102</b>, <b>103</b>, and <b>104</b> are mounted in the drive case <b>10</b><i>a</i>. Each of the disk blades includes a plurality of drives (four drives in this embodiment). For example, the disk blade <b>101</b> includes disks A<b>0</b> to A<b>3</b>. The disk A<b>0</b> and the like which are mounted in the drive case <b>10</b><i>a </i>using the disk blade <b>101</b> are connected with a connection interface <b>180</b> and can transmit and receive data to and from a disk array controller <b>191</b> and the like. An interface such as an ATA (AT Attachment), a SAS (Serial Attached SCSI), or a Fibre Channel can be used as the connection interface <b>180</b>.

0050The controller case <b>19</b> is provided with disk array controllers <b>191</b> and <b>192</b>. A control program operates in the disk array controller <b>191</b> or the like to control data input/output to and from the disk A<b>0</b> and the like. A RAID configuration implemented by the disk A<b>0</b> and the like which are mounted in the disk array apparatus <b>1</b> is managed according to the control program. Because the controller case <b>19</b> is provided with the plurality of disk array controllers <b>191</b> and <b>192</b>, the disk array controllers <b>191</b> and <b>192</b> simultaneously input/output a large amount of data to and from the SAN <b>4</b>.

0051The controller case <b>19</b> is provided with a power supply unit which supplies electric power to each unit in the disk array apparatus <b>1</b>.

0052According to a structure of the apparatus, the disk array controller <b>191</b> may be singly provided, or the controller case <b>19</b> and the drive case <b>10</b><i>a </i>may be provided as a single case.

0053The management terminal <b>2</b> is a computer apparatus including a CPU, a memory, a storage device, an interface, an input device, and a display device. A management program operates in the management terminal <b>2</b>. According to the management program, an operating state of the disk array apparatus <b>1</b> is checked for controlling the operation of the disk array apparatus <b>1</b>. Because a client program such as a web browser operates in the management terminal <b>2</b>, the operation of the disk array apparatus <b>1</b> may be controlled according to a management program (Common Gateway Interface, Java, or the like) supplied from the disk array apparatus <b>1</b>.

0054Each of the SAN hosts <b>3</b> is a computer apparatus including a CPU, a memory, a storage device, and an interface, and allows uses of a database service, a web service, and the like by using data supplied from the disk array apparatus <b>1</b>.

0055The SAN <b>4</b> is a network which allows communications via a protocol suitable for data transfer, such as a Fibre Channel protocol.

0056The management LAN <b>5</b> allows communications of data and control information between computers via, for example, a TCP/IP protocol. For example, an Ethernet is used.

0057<figref idref="DRAWINGS">FIG. 2</figref> is an external view showing the structure of the disk array apparatus according to the first embodiment of the present invention.

0058The disk array apparatus <b>1</b> according to the first embodiment of the present invention is stored in a 19-inch rack. Plural stages of drive cases (enclosures), each of which stores a plurality of disk blades including disks are provided in an upper portion of the disk array apparatus <b>1</b>. A power source unit (not shown) that supplies power to drives in a corresponding drive case and the connection interface <b>180</b> are provided on the rear side of each of the drive cases <b>10</b><i>a </i>to <b>10</b><i>i</i>. The connection interface <b>180</b> and the respective disk blades are physically connected with one another through a wiring board (back plane) provided in each of the drive cases. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the respective disk blades are connected with the disk array controller <b>191</b>, the drive case <b>10</b><i>a</i>, and the like.

0059The controller case <b>19</b> that stores the disk array controllers <b>191</b> and <b>192</b> and a cooling fan unit for cooling the disk array controllers <b>191</b> and <b>192</b> are provided below the drive cases.

0060<figref idref="DRAWINGS">FIG. 3</figref> is a perspective view showing the drive case <b>10</b><i>a </i>composing the disk array apparatus <b>1</b> according to the first embodiment of the present invention.

0061A plurality of disk blades <b>101</b> to <b>113</b> is attachable to the drive case <b>10</b><i>a</i>. The disk blades are stored in the drive case by sliding along a rail provided in the drive case.

0062Unit exchange indicators <b>121</b> to <b>133</b> are provided above the disk blades <b>101</b> to <b>113</b> in the drive case <b>10</b><i>a</i>. When a disk blade becomes ready to detach, the unit exchange indicator corresponding to the disk blade is turned on to give a notice, thereby facilitating maintenance and exchanging operations.

0063<figref idref="DRAWINGS">FIG. 4</figref> is an explanatory view showing a structure of the disk blade <b>101</b> composing the disk array apparatus according to the first embodiment of the present invention.

0064A plurality of drives <b>2010</b> to <b>2040</b> are attached to the disk blade <b>101</b>. The drives <b>2010</b> to <b>2040</b> are attached to holding frames (canisters) attachable to the disk blade <b>101</b> and constructed so as to be detached from the disk blade <b>101</b> together with the canisters. A connector is provided in the rear end of each of the drives <b>2010</b> to <b>2040</b>. The connector is fitted into a connector <b>2110</b> provided in the disk blade <b>101</b> to thereby connect between the drives <b>2010</b> to <b>2040</b> and the disk blade <b>101</b>.

0065Drive exchange indicators <b>2210</b> comprises LEDs, and are provided in the disk blade <b>101</b>. When the drives <b>2010</b> to <b>2040</b> (canisters) becomes ready to detach, the drive exchange indicator <b>2210</b> corresponding to the drive is turned on to give a notice, thereby facilitating maintenance and exchanging operations. The drive exchange indicators <b>2210</b> are driven by an LED control circuit <b>2300</b>. The LED control circuit <b>2300</b> turns on the drive exchange indicators <b>2210</b> based on instructions from the disk array controllers <b>191</b> and <b>192</b>.

0066Even after the disk blade <b>101</b> is detached from the drive case <b>10</b><i>a </i>(that is, even after power from the disk array apparatus <b>1</b> stops), the drive exchange indicators <b>2210</b> can stay tuned on. Therefore, the LED control circuit <b>2300</b> includes a memory circuit (for example, flip-flop) that holds the instructions from the disk array controllers <b>191</b> and <b>192</b> and a power source circuit (for example, rechargeable battery or capacitor) that supplies power applied to the drive exchange indicators <b>2210</b>. As described above, even after the disk blade <b>101</b> is detached from the drive case <b>10</b><i>a</i>, the drive exchange indicators <b>2210</b> stay turned on. Thus, even after the disk blade <b>101</b> is detached from the drive case <b>10</b><i>a</i>, a drive to be exchanged can be checked.

0067A connector <b>2400</b> is bonded to a back end of the disk blade <b>101</b>. The connector <b>2400</b> is fitted into a connector provided in the back plane to thereby connect between the disk blade <b>101</b> and the back plane.

0068A rotary switch <b>2500</b> is provided in the disk blade <b>101</b>. When a unit ID is set using the rotary switch <b>2500</b>, discrimination among the disk blades mounted in the same drive case can be electrically made. The rotary switch <b>2500</b> thus functions as a unit ID setting unit.

0069<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram showing the structure of the disk array controller <b>191</b> according to the first embodiment of the present invention.

0070The disk array controller <b>191</b> includes a CPU <b>1901</b>, a memory <b>1902</b>, a data transfer controller <b>1904</b>, a front end connection interface controller <b>1905</b>, a back end connection interface controller <b>1906</b>, a data buffer <b>1907</b>, and a LAN interface controller <b>1908</b>.

0071The memory <b>1902</b> stores a control program <b>1903</b> (see <figref idref="DRAWINGS">FIG. 6</figref>). The CPU <b>1901</b> calls and executes the control program <b>103</b> to execute various processings.

0072The data transfer controller <b>1904</b> transfers data among the CPU <b>1901</b>, the front end connection interface controller <b>1905</b>, the back end connection interface controller <b>1906</b>, and the data buffer <b>1907</b>.

0073The front end connection interface controller <b>1905</b> is an interface to the SAN <b>4</b> and transmits and receives data and control signals to and from the SAN hosts <b>3</b> via, for example, a Fibre Channel protocol.

0074The back end connection interface controller <b>1906</b> is an interface to the connection interface <b>180</b> and transmits and receives data and control signals to and from the disks through an interface such as an ATA, a SAS, or a Fibre Channel.

0075The data buffer <b>1907</b> includes a cache for temporarily storing data which is transmitted and received between the front end connection interface controller <b>1905</b> and the back end connection interface controller <b>1906</b>.

0076Therefore, the data transfer controller <b>1904</b> transfers between the interfaces <b>1905</b> and <b>1906</b> data which are read from and written to the disks through the SAN <b>4</b>. In addition, the data transfer controller <b>1904</b> transfers the data which are read from and written to the disks to the data buffer <b>1907</b>.

0077The LAN interface controller <b>1908</b> is an interface to the management LAN <b>5</b> and can transmit and receive data and a control signal to and from the management terminal <b>2</b> via, for example, an Ethernet protocol.

0078<figref idref="DRAWINGS">FIG. 6</figref> is an explanatory diagram showing the control program <b>1903</b> according to the first embodiment of the present invention.

0079The control program <b>1903</b> includes a RAID group setting program <b>1911</b>, a RAID group management program <b>1912</b>, a fault recovery program <b>1913</b>, and an I/O control program <b>1914</b>. In order to operate these programs, a drive setting content holding table <b>1915</b>, a drive state management table <b>1916</b>, a RAID group state management table <b>1917</b>; and a background processing number management table <b>1918</b> are stored.

0080By the RAID group setting program <b>1911</b>, the CPU <b>1901</b> executes processing for setting a RAID configuration using the drives mounted in the disk array apparatus <b>1</b> by the RAID group setting program <b>1911</b> (for example, see <figref idref="DRAWINGS">FIG. 13</figref>).

0081By the RAID group management program <b>1912</b>, the CPU <b>1901</b> maintains and manages of the RAID configuration set by the RAID group setting program <b>1911</b>.

0082By the fault recovery program <b>1913</b>, the CPU <b>1901</b>, monitors the fault in the drives mounted in the disk array apparatus <b>1</b> and executes of processing with respect to a drive in which the fault is caused and the drives included in the same unit as the drive in which the fault is caused (for example, see <figref idref="DRAWINGS">FIGS. 14</figref>, <b>15</b>, and <b>16</b>).

0083By the I/O control program <b>1914</b>, the CPU <b>1901</b> executes processing with respect to reading of data from and writing of data to the drives mounted in the disk array apparatus <b>1</b>.

0084Next, various tables used during the operations of the control program will be described.

0085<figref idref="DRAWINGS">FIG. 7</figref> is an explanatory diagram showing a RAID configuration implemented by the disks attached to the disk array apparatus <b>1</b> according to the first embodiment of the present invention.

0086For example, a RAID group <b>1</b> includes five drives, that is, a drive A<b>0</b> (unit ID is A and drive number is 0), a drive A<b>1</b>, a drive B<b>1</b>, a drive B<b>2</b>, and a drive C<b>2</b>, thereby composing a RAID group of level <b>5</b>. In addition, a RAID group <b>4</b> includes six drives such as a drive A<b>3</b>, a drive B<b>3</b>, a drive C<b>3</b>, a drive D<b>3</b>, a drive E<b>3</b>, and a drive F<b>3</b>, thereby composing a RAID group of level <b>6</b>.

0087<figref idref="DRAWINGS">FIG. 8</figref> is an explanatory diagram showing the drive setting content holding table <b>1915</b> according to the first embodiment of the present invention.

0088A state set to each of the drives included in each of the disk blades is recorded on each of the drive in the drive setting content holding table <b>1915</b>. Specifically, a storage capacity of each drive, a usage state (“in use” or “spare” which is not in use) of the drive, a RAID number of a RAID group to which the drive is assigned are recorded. More specifically, “1” is recorded in each of RAID number fields of the five drives such as the drive A<b>0</b>, the drive A<b>1</b>, the drive B<b>1</b>, the drive B<b>2</b>, and the drive C<b>2</b>, so that these drives are assigned to the RAID group <b>1</b>.

0089<figref idref="DRAWINGS">FIG. 9</figref> is an explanatory diagram showing the drive state management table <b>1916</b> according to the first embodiment of the present invention.

0090A current state of each of the drives included in each of the disk blades is recorded on each of the drive in the drive state management table <b>1916</b>. More specifically, a storage capacity of each drive, a state (“in use” “fault” which is caused, “rebuilding” which is executing rebuilding process, “refuging” which is executing refuging processing, or “spare” which is not in use) of the drive, a RAID number of a RAID group to which the drive is assigned are recorded. For example, the drive B<b>0</b> is a drive assigned to a RAID group <b>2</b> and a fault has occurred in the drive B<b>0</b>.

0091<figref idref="DRAWINGS">FIG. 10</figref> is an explanatory diagram showing the RAID group state management table <b>1917</b> according to the first embodiment of the present invention.

0092A total storage capacity, a RAID level (type of RAID configuration), a normal redundancy, a current redundancy, identification numbers of drives composing a RAID group, and a state of the RAID group are recorded for each set RAID group in the RAID group state management table <b>1917</b>.

0093For example, the drives composing the RAID group <b>1</b> are five drives A<b>0</b>, A<b>1</b>, B<b>1</b>, B<b>2</b>, and C<b>2</b>. These drives (that is, the RAID group <b>1</b>) operate in a normal state. On the other hand, the drives composing the RAID group <b>2</b> are five groups B<b>0</b>, C<b>0</b>, D<b>0</b>, E<b>0</b>, and F<b>0</b>. As shown in the drive state management table <b>1916</b> (<figref idref="DRAWINGS">FIG. 9</figref>), the fault has occurred in the drive B<b>0</b>, so that the RAID group <b>2</b> becomes a “fault” state. Thus, the normal redundancy of the RAID group <b>2</b> is one but the current redundancy reduces to zero.

0094<figref idref="DRAWINGS">FIG. 11</figref> is an explanatory diagram showing the background processing number management table <b>1918</b> according to the first embodiment of the present invention.

0095The background processing number management table <b>1918</b> shows disk blades (unit IDs) and the number of background processings executed in the disks included in each of the disk blades. That is, as described later, when the rebuilding processing starts after a fault occurs in a disk, the number of background processings increments (step S<b>130</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). When the rebuilding processing is complete, the number of background processings decrements (step S<b>167</b> shown in <figref idref="DRAWINGS">FIG. 15</figref>). In addition, when data copying processing starts after a fault occurs in a disk, the number of background processings increments (step S<b>141</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). When the data copying processing is complete, the number of background processings decrements (step S<b>176</b> shown in <figref idref="DRAWINGS">FIG. 16</figref>). In step S<b>145</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>, the background processing number management table <b>1918</b> is also used to judge whether a unit may be detached (a unit in which the background processing is maintained cannot be detached).

0096<figref idref="DRAWINGS">FIG. 12</figref> is an explanatory view showing a RAID group management screen displayed on the management terminal <b>2</b> according to the first embodiment of the present invention.

0097The RAID group management screen is displayed when an administrator selects a RAID group. The selected RAID group is displayed on a field of “selected group information” provided at the lower left of the RAID group management screen. The state of a disk is displayed on the RAID group management screen for each disk included in each of the disk blades.

0098An administrator selects drives composing a RAID group, so that the RAID group can be configured. An administrator can set the selected drive as “spare” which does not comprise the RAID group.

0099<figref idref="DRAWINGS">FIG. 13</figref> is a flow chart showing RAID group creation process according to the first embodiment of the present invention. The CPU <b>1901</b> executes the RAID group creation processing by using the RAID group setting program <b>1911</b>.

0100According to the RAID group setting program <b>1911</b>, when a RAID group creation request is received from the management terminal <b>2</b> (S<b>101</b>), the CPU <b>1901</b> temporarily registers a requested RAID group to the drive setting content holding table <b>1915</b>, the drive state management table <b>1916</b>, and the RAID group state management table <b>1917</b> (S<b>102</b>).

0101After that, the CPU <b>1901</b> refers to a unit described first in the drive setting content holding table <b>1915</b> (S<b>103</b>) and obtains a number s of drives which become spares in the unit (S<b>104</b>). The CPU <b>1901</b> searches a RAID group n which has a maximum number a of drives in the unit (S<b>105</b>). Then, the CPU <b>1901</b> obtains a redundancy r of the searched RAID group n with referred to the RAID group state management table <b>1917</b> (S<b>106</b>).

0102After that, the CPU <b>1901</b> compares (a−r+1) with ((the total number of spare drives)−s) to judges whether drives necessary to maintain the minimum redundancy remain as spares after the detachment of a unit (S<b>107</b>).

0103As a result of the judgment, when (a−r+1)>((the total number of spare drives)−s), the CPU <b>1901</b> determines that the number of spare drives necessary to maintain the minimum redundancy is insufficient in the case where the unit is detached. The CPU <b>1901</b> gives a notice of a RAID creation error due to the insufficiency of the spare drive (S<b>111</b>). Then, the CPU <b>1901</b> cancels the temporary registration of the respective management tables created in step S<b>102</b> (S<b>112</b>).

0104On the other hand, when (a−r+1)&lt;((the total number of spare drives)−s), the CPU <b>1901</b> determines that the number of spare drives necessary to maintain the minimum redundancy is sufficient even in the case where the unit is detached. Then, the CPU <b>1901</b> judges whether all units have been checked (S<b>108</b>).

0105As a result, when checking of all units is not complete, the processing goes to step S<b>113</b>. The next, the CPU <b>1901</b> selects a unit to be checked, and checks an influence at the time of detachment of the selected unit (S<b>104</b> to S<b>107</b>).

0106On the other hand, when the checking of all units is complete, the CPU <b>1901</b> formally registers the temporary registration of the respective management tables created in step S<b>102</b> to the respective tables (S<b>109</b>). Then, a notice of a creation success of the RAID group is sent to the management terminal <b>2</b> (S<b>110</b>).

0107<figref idref="DRAWINGS">FIG. 14</figref> is a flow chart showing unit exchange process at a time when a fault occurs in a drive according to the first embodiment of the present invention. The CPU <b>1901</b> executes the unit exchange processing by using the fault recovery program <b>1913</b>.

0108When a fault of a drive is detected (S<b>121</b>), the CPU <b>1901</b>, obtains a unit ID (α) of the fault drive, a drive number k thereof, and a number n of the RAID group to which the fault drive is assigned, and refers to the drive state management table <b>1916</b> (S<b>122</b>). Then, by the CPU <b>1901</b>, the state of the drive k which is recorded in the drive state management table <b>1916</b> is changed to “fault”, and the state of the RAID group n recorded in the RAID group state management table <b>1917</b> is changed to “fault” (S<b>123</b>). The CPU <b>1901</b> decrements current redundancy of the RAID group n which is recorded in the RAID group state management table <b>1917</b>, by one (S<b>124</b>).

0109In step S<b>125</b>, the CPU <b>1901</b> judges whether the current redundancy of the RAID group n is smaller than one (becomes zero).

0110As a result, when the current redundancy of the RAID group n is equal to or larger than one, the CPU <b>1901</b> determines that a minimum required redundancy is maintained. Then, the CPU <b>1901</b> initializes a variable i of the drive number, in order to check drives mounted in the same unit as the fault drive (S<b>132</b>). When the current redundancy of the RAID group n is smaller than 1, the processing goes to step S<b>126</b>.

0111In step S<b>126</b>, the CPU <b>1901</b> judges whether the current redundancy of the RAID group n is smaller than zero (becomes a negative value).

0112As a result, when the current redundancy of the RAID group n is smaller than zero, a notice indicating that no RAID configuration comprises and it occurs that data is lost is sent to a user (S<b>151</b>).

0113On the other hand, when the current redundancy of the RAID group n is equal to or larger than zero, the CPU <b>1901</b> searches a drive which becomes a spare, from units having unit IDs other than a (S<b>127</b>). As a result of the search, when the spare drive is not detected (S<b>128</b>), a notice for requesting the addition of a spare drive is sent to the user (S<b>152</b>). As a result of the search, when the spare drive is detected (S<b>128</b>), the CPU <b>1901</b> changes the state of the spare drive in the drive state management table <b>1916</b> to “rebuilding”. In addition, instead of information of the fault drive, the CPU <b>1901</b> adds information of the detected spare drive as composition drive information to the RAID group state management table <b>1917</b> (S<b>129</b>). The CPU <b>1901</b> increments number of background processings which is recorded in the background processing number management table <b>1918</b> with respect to the unit ID of a by one (S<b>130</b>). After that, the CPU <b>1901</b> executes data rebuilding of the RAID group n by the background processing (S<b>131</b>). The CPU <b>1901</b> initializes the variable i of the drive number (S<b>132</b>).

0114In step S<b>133</b>, when the variable i is initialized in step S<b>132</b>, the CPU <b>1901</b> compares the variable i with the drive number k of the fault drive which is obtained in step S<b>122</b>. As a result, when i=k, the CPU <b>1901</b> judges that a fault has occurred in this drive, and the processing goes to step S<b>143</b>. The CPU <b>1901</b> increments the variable i of the drive number by one and executes checking of the next drive. When i≠ k, the CPU <b>1901</b> judges that no fault has occurred in this drive, and the CPU <b>1901</b> obtains a number m of a RAID group to which a drive αi (the unit ID is a and the drive number is i) is assigned (S<b>134</b>). The CPU <b>1901</b> decrements the current redundancy of the RAID group m corresponding to the obtained number in the RAID group state management table <b>1917</b> by one (S<b>135</b>).

0115In step S<b>136</b> the CPU <b>1901</b> judges whether the current redundancy of the RAID group m is smaller than one (becomes zero).

0116As a result of the determination, when the current redundancy of the RAID group m is equal to or larger than one, the CPU <b>1901</b> determines that the minimum required redundancy is maintained. Then, the CPU <b>1901</b> increases a variable i of the drive number by one, in order to check the next drive (S<b>143</b>). When the current redundancy of the RAID group m is smaller than 1, the processing goes to step S<b>137</b>.

0117In step S<b>137</b>, the CPU <b>1901</b> judges whether the current redundancy of the RAID group m is smaller than zero (becomes a negative value).

0118According to the processings of steps S<b>136</b> and S<b>137</b>, a change in state of the RAID resulting from drives included in the unit whose unit ID is α is estimated the influence on the RAID group to which drives in which the no fault has occurred are assigned is estimated when the unit (unit ID is α) is detached.

0119As a result, when the current redundancy of the RAID group m is smaller than zero, a notice indicating that no RAID configuration comprises and data lost occurs is sent to a user (S<b>151</b>).

0120On the other hand, when the current redundancy of the RAID group n is equal to or larger than zero, the CPU <b>1901</b> searches a drive which becomes a spare, from units having unit IDs other than α (S<b>138</b>). As a result of the search, when the spare drive is not detected (S<b>139</b>), a notice for requesting the addition of a spare drive is sent to the user (S<b>152</b>). As a result of the search, when the spare drive is detected (S<b>139</b>), the CPU <b>1901</b> changes the state of the spare drive recorded in the drive state management table <b>1916</b> to “refuging” (S<b>140</b>). The CPU <b>1901</b> increases the number of background processings which is recorded in the background processing number management table <b>1918</b> with respect to the unit ID of α by one (S<b>141</b>). After that, data copying of the drive αi is executed by the background processing (S<b>131</b>). The processing goes to step S<b>143</b>, and the CPU <b>1901</b> increases the variable i of the drive number.

0121When the variable i is updated in step S<b>143</b>, the CPU <b>1901</b> judges whether the variable i exceeds the maximum value of the drive number (S<b>144</b>). As a result, when the variable i is smaller than the maximum value of the drive number, the processing returns to step S<b>132</b> and the CPU <b>1901</b> checks the next drive. When the variable i exceeds the maximum value of the drive number, checking of all drives is complete. Then, the CPU <b>1901</b> judges whether the number of background processings with respect to the unit ID of α is zero, with referring to the background processing number management table <b>1918</b> (S<b>145</b>). As a result, when the number of background processings with respect to the unit (unit ID α is not zero), that the background processing with respect to the unit (unit ID is α) is continued, and after the lapse of a predetermined time (S<b>146</b>), the CPU <b>1901</b> determines of executing step S<b>145</b> again. When the number of background processings with respect to the unit ID of a is zero, the CPU <b>1901</b> judges that the background processing is not executing on the unit (unit ID is α). The processing goes to step S<b>147</b>.

0122In step S<b>147</b>, the CPU <b>1901</b> changes a state of the unit (unit ID is α) in which no fault has occurred, which is recorded in the drive state management table <b>1916</b> to “not in use”. Then, the unit exchange indicator for the unit (unit ID is α) is turned on (S<b>148</b>) and the drive exchange indicator for the drive (drive ID is αk) is turned on (S<b>149</b>). After that, a notice for requesting the change of the unit (unit ID is α) is sent to the user (S<b>150</b>).

0123<figref idref="DRAWINGS">FIG. 15</figref> is a flow chart showing data rebuilding process to a RAID group according to the first embodiment of the present invention. The CPU <b>1901</b> executes data rebuilding processing by using the fault recovery program <b>1913</b>. The data rebuilding processing starts in step S<b>131</b> shown in <figref idref="DRAWINGS">FIG. 14</figref> and is executed by background processing.

0124The CPU <b>1901</b> reads data from all normal drives composing the RAID group n (S<b>161</b>). The CPU <b>1901</b> calculates Parity (exclusive OR) of the read data to obtain the same data as stored in the drive in which a fault has occurred, thereby restoring data (S<b>162</b>). Then, the restored data is written to the spare drive searched in step S<b>127</b> shown in <figref idref="DRAWINGS">FIG. 14</figref> (S<b>163</b>).

0125The CPU <b>1901</b> judges whether all data have been written (S<b>164</b>). As a result, when writing of all data is not complete, the processing returns to step S<b>161</b>. The CPU <b>1901</b> rebuilds a data using the data read from all normal drives composing the RAID group n. When writing of all data is complete, The CPU <b>1901</b> changes the state of the spare drive recorded in the drive state management table <b>1916</b> to “in use”. Then, the CPU <b>1901</b> updates a structure of drives recorded in the RAID group state management table <b>1917</b> and changes the state of RAID group n to “normal” (S<b>165</b>). The CPU <b>1901</b> increases the current redundancy of the RAID group n in the RAID group state management table <b>1917</b> by one (S<b>166</b>). The data rebuilding processing is complete by the background processing, so that the number of background processings with respect to the unit ID of α, which is recorded in the background processing number management table <b>1918</b> decrements by one (S<b>167</b>).

0126<figref idref="DRAWINGS">FIG. 16</figref> is a flow chart showing data copying process for a drive according to the first embodiment of the present invention. The CPU <b>1901</b> executes the data copying processing by using the fault recovery program <b>1913</b>. The data copying processing starts in step S<b>142</b> shown in <figref idref="DRAWINGS">FIG. 14</figref> and is executed by background processing.

0127First, data is read from a drive αN (unit ID is α and the drive number is N) (S<b>171</b>). The read data is written to the spare drive detected in step S<b>138</b> shown in <figref idref="DRAWINGS">FIG. 14</figref> (S<b>172</b>).

0128The CPU <b>1901</b> judges whether all data have been written (S<b>173</b>). As a result, when writing of all data is not complete, the processing returns to step S<b>171</b>. The CPU <b>1901</b> reads and copies the data. When writing of all data is complete, the CPU <b>1901</b> updates composing drives recorded in the drive state management table <b>1916</b>, and changes the state of the spare drive to “in use” (S<b>174</b>). The CPU <b>1901</b> increases the current redundancy of the RAID group n in the RAID group state management table <b>1917</b> by one (S<b>175</b>). The data copying processing is complete by the background processing, so that the CPU <b>1901</b> decreases the number of background processings with respect to the unit ID (α), which is recorded in the background processing number management table <b>1918</b> by one (S<b>176</b>).

0129<figref idref="DRAWINGS">FIG. 17</figref> is a flow chart showing exchangeable unit inserting processing according to the first embodiment of the present invention.

0130When a disk blade is inserted (S<b>181</b>), the CPU <b>1901</b> judges whether a correct unit is inserted according to a unit ID set in the inserted disk blade (S<b>182</b>). More specifically, it can be confirmed to judge whether the unit ID set in the inserted disk blade is equal to a unit ID set in a detached disk blade or to judge whether the unit ID set in the inserted disk blade is not a duplication of a unit ID of another unit which has been mounted.

0131After the CPU <b>1901</b> confirms that the correct unit is inserted, the unit exchange indicator for the inserted unit is turned off (S<b>183</b>).

0132The CPU <b>1901</b> selects a RAID group n to which drives of the inserted unit are assigned, with referring to the drive setting content holding table <b>1915</b> (S<b>184</b>).

0133After that, The CPU <b>1901</b> obtains the normal redundancy and the current redundancy of the RAID group n with referring to the RAID group state management table <b>1917</b> (S<b>185</b>). The CPU <b>1901</b> compares the normal redundancy and the current redundancy with each other (S<b>186</b>). As a result, when the current redundancy is smaller than the normal redundancy, the number of drives composing the RAID group n is insufficient as compared with the normal state. Thus, the CPU <b>1901</b> selects a drive into which data after rebuilding is written and changes the state of the drive recorded in the drive state management table <b>1916</b> to “rebuilding”. Then, the CPU <b>1901</b> executes data rebuilding of the RAID group n by background processing (S<b>187</b>).

0134After that, the CPU <b>1901</b> judges whether checking of all RAID groups to which the drives of the inserted unit are assigned is complete (S<b>188</b>). As a result, when the checking of all RAID groups is not complete, the CPU <b>1901</b> selects the next RAID group (S<b>189</b>) and the processing returns to step S<b>185</b> to check the redundancies of the selected RAID group. When the checking of all RAID groups is complete, the CPU <b>1901</b> changes a state of a drive which is not in use (that is, drive which is not used for data rebuilding in step S<b>187</b>) to “spare” (S<b>190</b>).

0135<figref idref="DRAWINGS">FIGS. 18 to 29</figref> show changes in the drive state management table <b>1916</b>, from a fault occurs in a drive B<b>0</b> to the unit B is exchanged.

0136Before the fault is caused the drive B<b>0</b> (unit ID is B and drive number is 0), the state of the drive B<b>0</b> is “in use” (<figref idref="DRAWINGS">FIG. 18</figref>).

0137When the fault occurs in the drive B<b>0</b>, the state of the drive B<b>0</b> becomes “fault” (step S<b>123</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). The state of a detected spare drive A<b>2</b> is changed to “rebuilding” (step S<b>129</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>) and data rebuilding of the drive B<b>0</b> to the spare drive A<b>2</b> starts (step S<b>131</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). <figref idref="DRAWINGS">FIG. 19</figref> shows a state of the data rebuilding of the drive B<b>0</b>. When the data rebuilding is complete, the state of the drive A<b>2</b> is changed to “in use”, so that the drive A<b>2</b> is used as the drive composing the RAID group <b>2</b> (<figref idref="DRAWINGS">FIG. 20</figref>).

0138After data rebuilding processing on the fault drive (or in parallel thereto), data refuging processing is executed on the drives B<b>1</b> to B<b>3</b>. The drive B<b>1</b> is assigned to the RAID group <b>1</b> and the RAID level of the RAID group <b>1</b> is RAID<b>5</b>, so that the redundancy is one. When the drive B<b>1</b> is removed, the redundancy becomes zero. Copying processing for refuging data of the drive B<b>1</b> starts.

0139That is, the state of a detected spare drive D<b>2</b> is changed to “refuging” (step S<b>140</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>) and copying of data of the drive B<b>1</b> to the spare drive D<b>2</b> starts (step S<b>142</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). <figref idref="DRAWINGS">FIG. 21</figref> shows a state of data refuging of the drive B<b>1</b>. When the data copying is complete, the state of the drive D<b>2</b> is changed to “in use”, so that the drive D<b>2</b> is used as the drive composing the RAID group <b>1</b> (<figref idref="DRAWINGS">FIG. 22</figref>).

0140Next, the data refuging processing is executed on the drive B<b>2</b>. The drive B<b>2</b> is assigned to the RAID group <b>1</b>. When the drive B<b>2</b> is removed, the redundancy becomes zero. Copying processing for refuging data of the drive B<b>2</b> starts. More specifically, the state of a detected spare drive E<b>2</b> is changed to “refuging” (step S<b>140</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>) and data copying from the drive B<b>2</b> to the spare drive E<b>2</b> starts (step S<b>142</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). <figref idref="DRAWINGS">FIG. 23</figref> shows a state of data refuging of the drive B<b>2</b>. When the data copying is complete, the state of the drive E<b>2</b> is changed to “in use”, so that the drive E<b>2</b> is used as the drive composing the RAID group <b>1</b> (<figref idref="DRAWINGS">FIG. 24</figref>).

0141Next, the data refuging processing is executed on the drive B<b>3</b>. The drive B<b>3</b> is assigned to the RAID group <b>4</b> and the RAID level of the RAID group <b>4</b> is RAID<b>6</b>, so that the redundancy is two. Even when the drive B<b>3</b> is removed, the redundancy maintains to be one. Therefore, it is determined to be unnecessary to save the data of the drive B<b>3</b> (step S<b>136</b> shown in <figref idref="DRAWINGS">FIG. 14</figref>). <figref idref="DRAWINGS">FIG. 25</figref> shows a state of data refuging of the drive B<b>3</b>.

0142When writing occurs during the refuging processing, write data is written to both the drive refuging source and the drive refuging destination. Therefore, even when data writing occurs during the refuging processing, data of the drive refuging source is not different from that of the drive refuging destination.

0143Then, processing on all drives of the unit B is complete, thereby completing the unit exchange processing (<figref idref="DRAWINGS">FIG. 14</figref>). <figref idref="DRAWINGS">FIG. 26</figref> shows a state at this time.

0144After that, when the unit B is detached and a new disk blade is attached, the states of all drives included in the unit B become “not in use” (<figref idref="DRAWINGS">FIG. 27</figref>). Then, the state of the drive B<b>3</b> into which data for rebuilding is written is changed to “rebuilding” and data rebuilding starts (<figref idref="DRAWINGS">FIG. 28</figref>). When the rebuilding is complete, the state of the drive B<b>3</b> into which data for rebuilding is written is changed to “in use” and the states of the drives (B<b>0</b> to B<b>2</b>) which are not in use are changed to “spare” (<figref idref="DRAWINGS">FIG. 29</figref>).

0145As described above, according to the first embodiment, when the unit (disk blade) is detached, the data rebuilding and data copying are executed so as to maintain the minimum redundancy of the RAID group related to the unit. After these processings are completed, the changes of the unit and the drive are instructed, so that the unit can be easily changed.

Second Embodiment

0146Next, a second embodiment of the present invention will be described. In the second embodiment, the guaranteed redundancy is set on each of the RAID group and it is controlled such that the redundancy of each RAID group is not below the guaranteed redundancy even when a fault occurs in a drive. In the second embodiment, only processings different from those in the first embodiment will be described and the description of the processings common to those in the first embodiment is omitted.

0147<figref idref="DRAWINGS">FIG. 30</figref> is an explanatory diagram showing a RAID group state management table <b>1917</b><i>b </i>according to the second embodiment of the present invention.

0148In addition to the same data as in the RAID group state management table <b>1917</b> according to the first embodiment (RAID group number, total storage capacity, RAID level, normal redundancy, current redundancy, identification numbers of drives composing RAID configuration, and RAID group state), the guaranteed redundancy is recorded in the RAID group state management table <b>1917</b><i>b</i>. The guaranteed redundancy is minimum redundancy guaranteed to the RAID group. Even when a fault has occurred in a drive assigned to the RAID group, it is controlled such that the redundancy of the RAID group does not become smaller than the guaranteed redundancy. The description of the same data as in the RAID group state management table <b>1917</b> according to the first embodiment is omitted.

0149<figref idref="DRAWINGS">FIGS. 31A and 31B</figref> are explanatory views showing a RAID group management screen according to the second embodiment of the present invention.

0150The RAID group management screen according to the second embodiment is different from the RAID group management screen according to the first embodiment (<figref idref="DRAWINGS">FIG. 12</figref>) and a “redundancy policy” bottom is provided thereon. When the “redundancy policy” bottom is operated, a redundancy policy setting screen shown in <figref idref="DRAWINGS">FIG. 31B</figref> opens. On the redundancy policy setting screen, a selection can be made as to whether the complete redundancy is constantly maintained, whether the minimum redundancy is maintained, or whether a temporary reduction in redundancy is allowed at the time of unit exchange on each of the RAID group.

0151<figref idref="DRAWINGS">FIG. 32</figref> is a flow chart showing guaranteed redundancy setting process according to the second embodiment of the present invention. The CPU <b>1901</b> executes the guaranteed redundancy setting processing by using the RAID group setting program <b>1911</b>.

0152First, when “complete redundancy is constantly maintained” is selected (S<b>261</b>), the CPU <b>1901</b> set the same value as the normal redundancy to the guaranteed redundancy to the RAID group state management table <b>1917</b><i>b </i>(S<b>262</b>). In addition, when “minimum redundancy is maintained” is selected (S<b>263</b>), one is set as the guaranteed redundancy in the RAID group state management table <b>1917</b><i>b </i>(S<b>264</b>). Further, when “temporary reduction in redundancy is allowed” at the time of unit exchange is selected (S<b>265</b>), zero is set as the guaranteed redundancy in the RAID group state management table <b>1917</b><i>b </i>(S<b>266</b>).

0153<figref idref="DRAWINGS">FIG. 33</figref> is a flow chart showing RAID group creation process according to the second embodiment of the present invention. The CPU <b>1901</b> executes the RAID group creation processing by using the RAID group setting program <b>1911</b>. The RAID group creation processing according to the second embodiment is the same to the RAID group creation processing according to the first embodiment (<figref idref="DRAWINGS">FIG. 13</figref>), except for step S<b>206</b> and thus the description of the same processings is omitted here.

0154After the CPU <b>1901</b> searches maximum number a of drives using in the RAID group n in step S<b>105</b>, the CPU <b>1901</b> obtains an guaranteed redundancy r of the searched RAID group n with referring to the RAID group state management table <b>1917</b> (S<b>206</b>).

0155After that, the CPU <b>1901</b> compares (a−r+1) with ((the total number of spare drives)−s) to judge whether drives necessary to maintain the minimum redundancy remain as spares after the detachment of a unit (S<b>107</b>).

0156As a result of the determination, when (a−r+1)>((the total number of spare drives)−s), the CPU <b>1901</b> judges that the number of spare drives necessary to maintain the guaranteed redundancy r is insufficient in the case where the unit is detached, and a notice of a RAID creation error due to the insufficiency of the spare drive is sent (S<b>111</b>). Then, the CPU <b>1901</b> cancels the temporary registration of the respective management tables created in step S<b>102</b> (S<b>112</b>).

0157On the other hand, when (a−r+1)≦((the total number of spare drives)−s), the CPU <b>1901</b> judges that the number of spare drives necessary to maintain the guaranteed redundancy r set to the RAID group n is sufficient even when the unit is detached.

0158<figref idref="DRAWINGS">FIG. 34</figref> is a flow chart showing unit exchange process at a time when a fault occurs in a drive according to the second embodiment of the present invention. The CPU <b>1901</b> executes the unit exchange processing by using the fault recovery program <b>1913</b>. The unit exchange processing according to the second embodiment is identical to the unit exchange processing according to the first embodiment (<figref idref="DRAWINGS">FIG. 14</figref>), except for steps S<b>225</b> and S<b>236</b> and thus the description of the same processings is omitted here.

0159After the current redundancy of the RAID group n corresponding to the obtained number in the RAID group state management table <b>1917</b> decrements by one in step S<b>124</b>, the CPU <b>1901</b> judges whether the current redundancy of the RAID group m is smaller than the guaranteed redundancy (S<b>225</b>).

0160As a result of the judgement, when the current redundancy of the RAID group n is equal to or larger than the guaranteed redundancy, the CPU <b>1901</b> initializes the variable i of the drive number (S<b>132</b>). When the current redundancy of the RAID group n is smaller than the guaranteed redundancy, the processing goes to step S<b>126</b>. In step S<b>126</b>, the CPU <b>1901</b> judges whether the current redundancy of the RAID group n is smaller than zero.

0161After the current redundancy of the RAID group m corresponding to the obtained number in the RAID group state management table <b>1917</b> decrements by one in step S<b>135</b>, whether the current redundancy of the RAID group m is smaller than the guaranteed redundancy is determined (S<b>236</b>).

0162As a result of the judgement, when the current redundancy of the RAID group m is equal to or larger than the guaranteed redundancy, the CPU <b>1901</b> the variable i of the drive number is incremented by 1 (S<b>143</b>). When the current redundancy of the RAID group m is smaller than the guaranteed redundancy, the processing goes to step S<b>137</b>. In step S<b>137</b>, the CPU <b>1901</b> judges whether the current redundancy of the RAID group m is smaller than zero. According to the processings of steps S<b>236</b> and S<b>137</b>, the CPU <b>1901</b> estimates a change in RAID group state resulting from drives included in the unit whose unit ID is α. That is, the influence on the RAID group to which drives in which the no fault has occurred are assigned is estimated when the unit (unit ID is a) is detached.

0163As described above, according to the second embodiment, the guaranteed redundancy is set to each of the RAID group and it is controlled such that the redundancy of the RAID group is not below the guaranteed redundancy even when a fault occurs in a drive. Thus, the redundancy can be controlled according to a required performance (that is, importance of stored data) for each RAID group.

Third Embodiment

0164Next, a third embodiment of the present invention will be described. In the third embodiment, drive maintenance information is provided. The third embodiment can be additionally applied to the first and second embodiments.

0165<figref idref="DRAWINGS">FIG. 35</figref> is an explanatory view showing a RAID group management screen according to the third embodiment of the present invention. In the RAID group management screen according to the third embodiment, a display field for the drive maintenance information is provided in a lower region thereof.

0166<figref idref="DRAWINGS">FIG. 36</figref> is a flow chart showing urgent maintenance notice determination processing according to the third embodiment of the present invention. The drive maintenance information is displayed on the RAID group management screen is selected.

0167First, the CPU <b>901</b> refers to a unit described first in the drive setting content holding table <b>1915</b> (S<b>301</b>) and obtains a number s of drives which become spares in the unit (S<b>302</b>). The CPU <b>1901</b> searches maximum number a of drives using in a RAID group n (S<b>303</b>). Then, the CPU <b>1901</b> obtains the redundancy r of the searched RAID group n with referring to the RAID group state management table <b>1917</b> (S<b>304</b>).

0168After that, the CPU <b>1901</b> compares (a−r+1) with ((the total number of spare drives)−s) to judges whether drives necessary to maintain the minimum redundancy remain as spares after the detachment of a unit (S<b>305</b>).

0169As a result of the determination, when (a−r+1)>(the total number of spare drives)−s), the guaranteed redundancy cannot be maintained if a fault occurs in a drive. Thus, the CPU <b>1901</b> judges that the number of spare drives necessary to maintain the guaranteed redundancy r set to the RAID group n is insufficient even when the fault occurs in the drive. Then, a notice indicating that the maintenance urgency is high (it is necessary immediately to exchange fault drive or to immediately add drive) is sent (S<b>309</b>).

0170On the other hand, when (a−r+1)≦((the total number of spare drives)−s), the CPU <b>1901</b> judges that the number of spare drives necessary to maintain the guaranteed redundancy r set to the RAID group n is sufficient even when the unit is detached. Then, the CPU <b>1901</b> judges whether all units are checked (S<b>306</b>).

0171As a result, when checking of all units is not complete, the processing goes to step S<b>307</b> to select the next unit to be checked. Then, the processing returns to step S<b>302</b> to continue the checking of the next unit.

0172On the other hand, when the checking of all units is complete, the guaranteed redundancy can be maintained even when a fault occurs in a single drive. Thus, a notice indicating that the maintenance urgency is low is sent (S<b>308</b>).

0173The above-mentioned urgent maintenance notice determination processing according to the third embodiment can be applied to the second embodiment. When not the guaranteed redundancy but the current redundancy of the RAID group n is used in steps S<b>304</b> and S<b>305</b>, the urgent maintenance notice determination processing can be applied to the first embodiment.

0174As described above, according to the third embodiment, the drive maintenance information is provided to maintain the redundancy of the RAID group, so that the redundancy of the RAID group can be prevented from reducing lower than an expected value. In addition, a low urgent maintenance can be omitted by the urgency judgment, so that the maintenance can be performed at a time as compared with a conventional maintenance which should be performed plural times, thereby reducing cost and time for maintenance.

0175While the present invention has been described in detail and pictorially in the accompanying drawings, the present invention is not limited to such detail but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims.