If the class status is one of the following statuses, take action as indicated for the relevant situation.
(1) Class becomes closed status during operation.
Explanation
The class becomes closed when the number of configuration databases which store information on object configuration and object status within a class is insufficient, or when the communication error between nodes occurs in a cluster environment. All objects within a closed class are inaccessible.
An Insufficient number of configuration databases will occur under the following conditions:
When there are no disks that can be accessed normally, if there are two or less disks in ENABLE status.
When there are one or less disks that can be accessed normally, if there are three to five disks in ENABLE status.
When there are two or less disks that can be accessed normally, if there are more than six disks in ENABLE status.
However, in the event of root class, the class will not be closed unless there are no accessible disks.
GDS configuration databases cannot be stored in BCV devices and target (R2) devices of Dell EMC storage units since the devices are overwritten by data in copy source disks. Therefore, GDS does not regard BCV devices and target (R2) devices as "disks that can be accessed normally" described in the above conditions.
Resolution
1) You can check whether or not a class was closed during operation as follows. Do not reboot the system or restart sdxservd daemon, as it will make the checking impossible.
# /etc/opt/FJSVsdx/bin/sdxdcdown |
In this example, Class2, Class3, and Class4 with "yes" in the DOWN field are closed. The cause shown in the REASON fields are as follows.
Comm Communication failure between nodes.
FewDB Insufficient number of valid configuration databases.
NoDB No valid configuration database.
2) Depending on specific causes, recovery may be difficult. First, collect the investigation material.
For information on how to collect the investigation material, see "F.2 Collecting Investigation Material."
Resolutions are described for the following two cases:
Closed due to a communication error
Closed due to an insufficient number of configuration databases
3a) In the event of (Cause 1), contact field engineers.
3b) In the event of (Cause 2) or (Cause 3), all (or the majority) of the disks registered with class have abnormalities.
You can check the disks registered with class as follows.
# sdxinfo -D -c Class3 |
In this example, ten disks from Disk31 to Disk40 are registered with Class3. Physical disk names are shown in the DEVNAM field. Identify the cause of abnormality with these physical disks by referring to disk driver log messages. The cause of abnormality could be either of the following:
Failed or defective non-disk component.
Failed disk component.
4b) In the event of (Failure 1), recover the failed or defective non-disk component (such as I/O adapter, I/O cable, I/O controller, power supply, and fan).
5b) For a local class or a shared class, execute the sdxfix command to restore the class status.
# sdxfix -C -c Class3 |
If the sdxfix command ends normally, skip steps 6b) through 9b) and go on to step 10b).
If the sdxfix command does not end normally, go on to step 6b).
For the root class, go on to step 6b).
6b) Open the GDS configuration parameter file with an editor.
# vi /etc/opt/FJSVsdx/sdx.cf |
Add the following one line in the end of the file.
SDX_DB_FAIL_NUM=0
7b) Reboot the system.
8b) Confirm that objects within the class are accessible.
# sdxinfo -c Class3 |
If nothing is displayed, recovery was unsuccessful. You will have to contact field engineers. If information is displayed normally, proceed with the following procedures.
9b) In the event of (Failure 2), where a disk component has failed, follow the procedures in "5.3.4 Disk Swap," or "D.8 sdxswap - Swap disk," and swap the disks.
10b) After completing the recovery for both (Failure 1) and (Failure 2), check the number of valid configuration databases as described below.
# /etc/opt/FJSVsdx/bin/sdxdcdown |
NLDB field gives the insufficient number of configuration databases. If this value is "0," the problem is resolved. If this value is "1" or more, there are still disks that have not been recovered. In the above example, all NLDB fields display "0," indicating the successful recovery.
When step 6b) was not performed, the following procedures are not required.
11b) Open the GDS configuration parameter file with an editor.
# vi /etc/opt/FJSVsdx/sdx.cf |
Remove the following one line added in step 6b).
SDX_DB_FAIL_NUM=0
12b) Reboot the system.
If you cannot perform the recovery with the described procedures, contact field engineers.
(2) Class cannot be started when booting the system
Explanation
When booting the system, if the configuration database that contains the configurations and status of objects in the class is not accessible due to an I/O error of the disk or similar causes, the class remains unstarted.
All objects in the class that remains unstarted are not accessible. Also, the class which remains unstarted will not display related objects or any other class information even running the sdxinfo command.
Resolution
1) Identify the cause by referring to the sfdsk and disk driver message output on the console, and recover the class.
2) See (Cause a) and (Cause b) in section "(1) Disk is in DISABLE status." in "F.1.2 Disk Status Abnormality", and take the corresponding resolution measures.
In any of the following situations, contact field engineers, as the corresponding class must be forcibly removed and then recreated.
If you have mistakenly formatted a disk that is registered with GDS when operating an ETERNUS Disk storage system or other server case.
