2.3.6 SCSI reservation for shared disk
SCSI reservation for shared disk is a lock function for a shared disk in which the active system reserves the shared disk so that only the active system can access the shared disk. This protects the shared disk from data corruption that might result from concurrent write operations from multiple systems.
If hot standby has been enabled and HA Monitor detects a failure, HA Monitor uses SCSI reservation for shared disk and then starts the target server.
You must decide whether to use this function. For details about how to decide, see 1.4 Hot-standby switchover methods and 3.1 List of functions supported by HA Monitor.
You use SCSI reservation for shared disk by specifying the following HA Monitor environment settings:
-
fence_reset operand: nouse
-
fence_scsi operand: use
For details about these operands, see 8.3.1 HA Monitor environment settings (sysdef). If a specified setting is invalid, the KAMN977-W message is issued, but processing continues.
- Organization of this subsection
(1) Reservation during server start and termination
The active server is started after the shared disk to be used by the server has been reserved. The reservation is obtained before the shared disk is connected.
When the active server is terminated, the reservation obtained when the active server was started is released once the server's termination processing has been completed. The reservation is released after the shared disk is disconnected.
There is no reservation-related processing when the standby server is started or terminated.
The following table lists and describes the messages that are issued when reservation has failed and describes the subsequent processing.
|
Case |
Message that is issued |
Subsequent processing |
|---|---|---|
|
Reservation of the portion of the shared disk to be used by the server has failed due to a shared disk path failure. |
KAMN725-W, KAMN726-E |
Server startup processing continues. |
|
Reservation has failed because the portion of the shared disk to be used by the server has already been reserved by another system. |
KAMN725-W, KAMN726-E |
Server startup processing is canceled. |
|
Reservation of the entire shared disk to be used by the server has failed. |
KAMN725-W, KAMN726-E, KAMN498-E |
Server startup processing is canceled. |
|
Release of reservation has failed for all or part of the shared disk. |
KAMN725-W, KAMN726-E |
Processing continues. |
(2) Reservation during the hot standby operation
Reservation is handled as explained below during the hot standby operation.
- In the event of a server failure or during planned hot standby:
-
After the source host releases reservation, the target host forcibly obtains reservation and then starts the standby server as the active server. If release of resources has failed on the target host, an OS panic is generated on the source host.
- In the event of a host failure due to an OS or HA Monitor failure:
-
Because the source host does not release the reservation, the target host forcibly obtains reservation and then starts the standby server as the active server. At this time, in the event of a process failure on the HA Monitor on the source host, the KAMN066-E message is output and an OS panic is generated. This prevents contention for shared resources.
If the switching-source server is standing by again before the system switching-destination server is stopped, it outputs the KAMN728-W message, and then stops the server without releasing the reservation. When the alive message is blocked due to the slowdown of the OS in the active server, and the reservation is released after the shared disk is updated in the switched system, the system recovers from the slowdown later and might update the shared disk and destroy the data.
If the server is stopped without releasing the reservation, make sure that there is no active server on another host, release the reservation, and then start the active server.
- In the event of a host failure due to a monitoring path failure:
-
The HA Monitor in the standby system detects the host failure in the active system and performs the hot standby operation. As a result, the reservation obtained by the active system is assumed forcibly by the standby system.
The HA Monitor in the active system detects the loss of reservation, issues the KAMN666-E message, forcibly terminates the server in the active system, and then disconnects the shared resources. The methods used for server termination and shared disk processing during the hot standby operation are the same as when the hot standby operation is performed.
Note that HA Monitor does not recognize monitoring path failures and OS slowdown in the active system as host failures. If these failures occur and the target server needs to be terminated, HA Monitor issues the KAMN728-W message and terminates the server without releasing reservation, in the same manner as when a host failure has occurred due to an OS failure or HA Monitor failure. If the monitoring path is restored and the source server is placed in standby status again before the target server has terminated, HA Monitor releases the reservation when the target server is terminated and does not issue the KAMN728-W message.
The following figure shows the processing flow in the event of a monitoring path failure.
Figure 2‒15: Processing flow in the event of a monitoring path failure ![[Figure]](GRAPHICS/F0000030.GIF)
If a failure has occurred on the disk path from the standby system, the HA Monitor in the standby system assumes that reservation has failed and terminates the standby server without reserving any part of the shared disk needed by the server. The active system continues active server operation because it maintains the reservation.
The following figure shows the processing flow in the event of a monitoring path failure when a failure has occurred in some of the disk paths in the standby system.
Figure 2‒16: Processing flow in the event of a monitoring path failure when a failure has occurred in some of the disk paths in the standby system ![[Figure]](GRAPHICS/F0000031.GIF)
The following are details of the processing flow shown in the figure. The numbers correspond to the numbers in the figure.
-
A failure has occurred on one of the shared disk paths in the standby system.
-
A monitoring path failure has occurred.
-
The standby system detects the host failure and performs the hot standby operation, but cannot obtain reservation because the path failure occurred in a part of the shared disk. As a result, the hot standby operation fails.
-
The active system continues job processing because it maintains the reservation.
-
(3) Checking the reservation status
To be prepared to perform the hot standby operation, HA Monitor periodically checks the reservation status. This subsection describes the checking of reservation status from the active and standby systems.
(a) Checking the reservation status from the active system
From the active system, HA Monitor periodically checks the reservation status on all shared disks that are used by the server. Specifically, it checks for a forced reservation from the remote system for the purpose of performing hot standby switching to the standby system due to a monitoring path failure.
You use the scsi_check operand in the HA Monitor environment settings to specify the check interval. The default value is five seconds.
(b) Checking the shared disk path status from the standby system
HA Monitor monitors the disk path status by obtaining the shared disk status from the standby system. Hot standby errors can be avoided by checking for any abnormality in advance and then notifying the user. The hot standby operation fails if reservation of a portion or all of the shared disk cannot be obtained.
You use the scsi_pathcheck operand in the HA Monitor environment settings to specify the check interval. The default value is one minute.
If HA Monitor detects a disk path error, it issues the KAMN725-W and KAMN726-E messages.
If HA Monitor detects recovery of the disk path, it issues the KAMN727-I message.
(4) When there is a server that does not use a shared disk
A shared disk is required in order to obtain a reservation. If the active server does not use a shared disk, it might not be able to detect the hot standby operation that results from a failure, such as a monitoring path failure.
However, reservation can be obtained in a system configuration that consists both of servers that use a shared disk and of servers that do not use a shared disk. Therefore, if there are servers that do not use a shared disk, you must specify either of the settings in the following table.
|
Setting |
Advantage |
Disadvantage |
|---|---|---|
|
Provide a shared disk (for reservation use only) for the servers that do not use a shared disk, and define the provided shared disk for the scsi_device or dmmp_device operand in the server environment definition. |
Because these servers do not have a parent-child relation with other servers, they are not affected by order control. |
A new shared resource that will not be used for actual operation must be added as a shared disk for reservation use only. |
|
Make a group of the servers that use a shared disk and a group of the servers that do not and then make sure that both groups of servers are run together. Specific examples of this setting are as follows:
|
A shared disk for reservation use only is not necessary. |
The servers that use a shared disk and the servers that do not use a shared disk have a parent-child relation. Therefore, order control produces the following effects:
|
(5) Notes
In the following cases, the reservation that was obtained cannot be released:
-
When the OS is shut down while an active server is running
-
When the reservation fails to release when an active server terminates
-
When the active server is terminated after hot standby processing was performed because of a host failure but before the failed host and standby server are started
-
When a host failure occurs on the active system while hot standby is not possible, such as when the standby server is inactive
The reservation that has been obtained might not be released in the following case:
-
When the reservation was obtained by a user operation
If you try to start an active server without the reservation having been released, the active server fails to start. In this case, make sure that there is no active server on another host, release the reservation, and then start the active server. For instructions on checking and releasing reservations, see 7.5.6 Handling device failures on a shared disk (while the active server is starting) (using SCSI reservation for shared disk) and 7.5.8 Handling device failures on a shared disk (while the active server is terminating) (using SCSI reservation for shared disk).
These procedures for releasing reservations and the procedure described in 7.5.7 Handling device failures on a shared disk (while the active server is running) (using SCSI reservation for shared disk) use the sg_persist command. If the sg_persist command is not installed, install the sg3_utils and sg3_utils-libs packages provided with Linux.
If you release reservations without using the reservation release command (monscsiclr command), you must execute the sg_persist command multiple times. To be able to release reservations with a single procedure, we recommend that you create a shell for releasing reservations in advance. For details about creating a shell for releasing reservations in advance, see 7.5.11 Dealing with the server that does not release the reservation (using SCSI reservation for shared disk).