Figure 25-29 shows shared disk allocation.
Figure 25-29 Shared disk allocation
![[Figure]](figure/zu250880.gif)
- Explanation
- When you use the standby system switchover facility or the standby-less system switchover (1:1) facility, allocate a shared disk to each unit because system switchover occurs on a unit-by-unit basis.
- When you use the standby-less system switchover (effects distributed) facility, allocate a shared disk to each server because system switchover occurs on a server-by-server basis. You cannot store information from multiple servers in a single shared disk.
The following HiRDB file system areas are created in a shared disk unit:
- HiRDB file system area for RDAREAs
- HiRDB file system area for system files
- HiRDB file system area for backup files
- HiRDB file system area for unload log files
- Notes
- Set up these HiRDB file system areas so that the HiRDBs of both the primary system and the secondary system can reference the shared disk unit using the same path name. When you use the standby-less system switchover (1:1) facility, set up these HiRDB file system areas so that both the normal BES unit and the alternate BES unit can reference the shared disk unit using the same path name. When you use the standby-less system switchover (effects distributed) facility, set up these HiRDB file system areas so that all units within the HA group can reference the shared disk unit using the same path name. However, for the standby-less system switchover (effects distributed) facility, create the unit status file in an independent, non-shared disk that is different from those used for server status files, system log files, and synchronization point dump files.
- The shared disk in which HiRDB file system areas for shared RDAREAs are created must be activated in the write mode from all units. For this reason, the disk must not be deactivated or activated in conjunction with system switchover.
- Only HiRDB file system areas created in character special files can be shared. HiRDB file system areas in regular files cannot be shared.
- Do not use regular files on a shared disk. If system switchover occurs when regular files are in a status that does not apply to shared disks (for example, data remains in the operating system cache even though HiRDB finished writing it to the target files), any updates made to the files may be lost.
When the system switchover source and target both attempt to access the shared disk at the same time while the system switchover facility is being used, the database may become corrupted. For this reason, accesses from the system to the shared disk must be controlled. This shared disk access control is performed by either the cluster software or HiRDB.
Normally, the method described in (a) Shared disk access control by the cluster software is used to perform access control on the shared disk. To use the method described in (b) Shared disk access control by HiRDB, HA monitor 01-08 or later is required.
(a) Shared disk access control by the cluster software
The cluster software can perform access control on the shared disk. It exercises controls so that the running system is active and the standby and stopped systems are inactive, which means that only the running system can access the shared disk. Figure 25-30 shows how the cluster software exercises control over shared disk access.
Figure 25-30 Shared disk access control by the cluster software
![[Figure]](figure/zu255201.gif)
- Explanation
- Because an inactive system cannot access the shared disk, only the running system is capable of accessing the shared disk.
For details about the shared disk switching method (between active and inactive), see the cluster software documentation.
If you are using HA monitor, you must specify the disk operand in the HA monitor's servers definition statement.
(b) Shared disk access control by HiRDB
To use HiRDB to perform access control on the shared disk, HA monitor 01-08 or later is required.
HiRDB can perform access control on the shared disk. In such a case, shared disk switching (between active and inactive) is not performed. System switchover takes place in the following sequence:
- A failure that results in system switchover occurs.
- HiRDB confirms that all processes (HiRDB processes) have terminated in the source system.
- System switchover takes place.
- The target system starts accessing the shared disk.
Figure 25-31 shows the shared disk access control that is provided by HiRDB.
Figure 25-31 Shared disk access control by HiRDB
![[Figure]](figure/zu255202.gif)
- Criteria
You should use HiRDB to perform shared disk access control in the following cases:
- When the Linux OS in being used
Character special files on LVM are not supported in the Linux version, but LVM is required by a shared disk whose access is to be controlled by the HA monitor. For this reason, the method described in (a) Shared disk access control by the cluster software cannot be used.
- When shared RDAREAs are used
When shared RDAREAs are used, the shared disk that contains a shared RDAREA must be made active from all server machines where a back-end server is located. If an updatable back-end server and a reference-only back-end server are both located in the same server machine, the updatable back-end server becomes the target of system switchover. If shared disk switching occurs in such a case, the shared RDAREA can no longer be referenced from the reference-only back-end server. Therefore, the method described in (a) Shared disk access control by the cluster software cannot be used.
- When Real Time SAN Replication is used in the log-only synchronous method
When Real Time SAN Replication is used in the log-only synchronous method, TrueCopy is used at the log application site to copy system files from a remote location. When TrueCopy is used, LVM cannot be used, but LVM is required for a shared disk whose access is to be controlled by the HA monitor. For this reason, the method described in (a) Shared disk access control by the cluster software cannot be used.
- HiRDB environment settings
You must specify the following operands in the HiRDB system definition:
- pd_ha_prc_cleanup_check = Y
When Y is specified in this operand, system switchover takes place only after all processes have terminated in the unit. In the case of the standby-less system switchover (effects distributed) facility, system switchover is executed after all processes have terminated at the back-end servers.
- pd_ha_switch_timeout = Y
System switchover may be delayed for a reason such as ongoing disk I/O processing. When Y is specified in this operand, the HA monitor treats it as a server (HiRDB) slowdown and resets the system, so that system switchover can take place.
- HA monitor environment settings
The following are the operand specification requirements in the HA monitor's servers definition statement:
- pairdown
You must specify use:serv_slow in this operand.
Termination of processes may not be confirmed, such as when a process does not terminate at the source system or when HiRDB slows down. Such an event prevents system switchover from being executed. When this operand is specified, the system is reset to allow execution of system switchover when termination of processes cannot be confirmed for a reason such as a slowdown.
- disk
Omit this operand because the HA monitor is not used to perform access control on the shared disk.