Number of disks within the class
If using the hot spare function with a local class or shared class, the number of disks including the spare disks within the class is to be set to four or more. If the number of disks within the class is three, the spare disk will not be effective.
For the configuration in example 1, with only the SCSI Bus#0 malfunctioning, the class gets closed down and the transactions stop.
For the configuration in Example 2, after one of the disks has malfunctioned and the spare disk has been connected to the mirror group, the class gets closed down and transactions stop when one more disk malfunctions.
By increasing the number of disks within the class, it is possible to avoid the transaction stop caused by a single hardware malfunction.
If using the root class, insofar as there is a normal disk, the class will not close down, so setting the number of disks within the root class including the spare disk to three is not a problem.
Hot Spare for Hierarchized Mirror Groups
If an I/O error occurs in a disk that is connected to a lower level group, a spare disk is automatically connected to the highest level mirror group, but not to the lower level group. Therefore, the capacity of the spare disk must be larger than the available size of the lower group.
A spare disk is selected independently of the disk case or controller number of a disk where an I/O error occurred.
In external hot spare mode (default), spare disks are selected randomly.
In internal hot spare mode, spare disks whose controller number is 0 and that do not belong to disk array units are selected.
Number of Spare Disks
There is no limit to the number of spare disks that can be registered with one class. Although there is no general rule in deciding the number of spare disks, it is recommended to assign 10% of disks and lower level groups for spare disks. In other words, one spare disk for every 10 disks or lower level groups combined is a good rule of thumb.
Spare Disk Size
Spare disk automatic connection is restrained if there is not sufficient space on a spare disk to copy volumes in a mirror group. It is recommended to assign the largest size disk within the class for the spare disk.
Hot Spare for Proxy Volumes
Spare disks are not connected to groups that include proxy volumes. It is recommended to create proxy volumes in groups other than those that include volumes used by primary services, or on single disks.
Shadow Classes
Spare disks cannot be registered with shadow classes.
Disk Array Unit's Hot Spare Function
If disk array units with hot spare functions are mirrored, it is recommended to use their own hot spare functions.
Spare Disk Failure
If an I/O error occurs in a spare disk that was automatically connected to a mirror group, another spare disk will not automatically be connected in place of the failed spare disk.
Synchronization Copying Invoked by Hot Spare
The synchronization copying with hot spare is run at lower speed as compared to similar copying with other events (such as volume creation and disk creation) in order to suppress the load imposed on the system. By default, delay time by 10 milliseconds is set. To change this delay time, use the sdxparam command.
Required time for Synchronization Copying Invoked by Hot Spare
The required time for synchronization copying invoked by hot spare depends on the performance of the CPU or disk. You can estimate the indication of the required time by the following formula:
Total volume size (GB) x 0.5 (minute) + (Total volume size (Block) / 256) x spare_copy_delay (milliseconds)
You can check the value of spare_copy_delay (delay time for synchronization copying invoked by hot spare) with the sdxparam --G.
See
For details, see "D.12 sdxparam - Configuration parameter operations."
General notes when upgraded from 4.3A40 or earlier versions
From 4.5A00, synchronization copying invoked by hot spare is improved and its processing time is reduced compared to 4.3A40 or earlier.
However, if 4.3A40 or earlier version is used, and the parameter value (spare_copy_delay) of delay time of the synchronization copying invoked by hot spare has been changed from the default value (50 milliseconds) to the value other than10 milliseconds, the reduced processing time of synchronization copying is not enabled even in upgraded 4.5A00.
When enabling the reduced processing time of synchronization copying, do the following settings. For cluster system, set on all the nodes.
Check the delay time configuration of synchronization copying invoked by hot spare.
# sdxparam -G -p spare_copy_delay
If the delay time configuration is spare_copy_delay=10, the following settings are not necessary.
Change the delay time of synchronization copying invoked by hot spare to 10 milliseconds.
# sdxparam -S -p spare_copy_delay=10
Check if the setting is correct.
# sdxparam -G -p spare_copy_delay
spare_copy_delay=10
Spare Disk Manual Connection
In the within-case hot spare mode, if a disk case totally becomes inaccessible due to an I/O cable coming out or disk case going down, a spare disk that belongs another disk case is not automatically connected. For example, if disk case 1 shown in [Figure 1.11 Hot Spare in Internal Mode] of "1.2.2 Hot Spare" is down, a spare disk (disk 4) is not automatically connected in place of disk 1.
In such an event, follow the procedures below to manually recover the mirroring status by using a spare disk.
Change the spare disk to an undefined disk.
See
For disk type changing methods, see "Changing the Class Attributes" in "5.4.1 Class Configuration" when using the GDS Management View, or "D.7 sdxattr - Set objects attributes" when using the command.
Connect the disk in step 1. to the mirror group where the I/O error occurred.
See
For the disk connection methods, see "5.4.2 Group Configuration" when using the GDS Management View, or the description about the -C option in "D.2 sdxdisk - Disk operations" when using the command.
Note
When an I/O error occurs in a disk of the disk array unit, in order for the Hot Spare functions to work as specified by the Hot Spare mode, the configuration must fulfill the following three conditions:
The multiplicity of mirroring is two.
The two disks to be mirrored belong to different disk array cases.
The spare disks, which are registered in the classes to which the mirrored disks belong, are in the same disk array cases to which the mirrored disks belong.