6.10.1 Setting Contents of a Cluster Application

How to failover a node in the event of a double fault

Perform the following operation:

-> HaltFlag = 1 (yes)

-> AutoSwitchOver = HostFailure | ResourceFailure | Shutdown

If "No" has been set to HaltFlag, a failover is not performed even in the event of a double fault. Setting "Yes" to HaltFlag allows the Shutdown Facility to stop the failed node forcibly (PANIC, power discontinuity, and reboot) in the event of a double fault. Then, a failover is performed.

Note

Even though the AutoSwitchOver attribute has been set, a failover is not performed unless HaltFlag has been set in the event of a double fault.

How to failover a userApplication in the event of a node failure, resource failure, and RMS stop

Perform the following operation:

-> AutoSwitchOver = HostFailure | ResourceFailure | Shutdown

Note

In the event of a double fault, a failover is not performed even though this attribute value has been set.
Set the HaltFlag attribute for performing a failover even in the event of a double fault.
When the status of the userApplication to be switched is Fault, it cannot be switched even though HostFailure and Shutdown have been set, and also a host failure or shutdown occurs.
When performing a failover in the event of a resource failure, clear the Faulted state.

How to start up a userApplication automatically in the event of a startup, switchover, and clearing a fault

Perform the following operation:

-> AutoStartUp = 1 (yes)

-> StandbyTransitions = Startup | SwitchRequest | ClearFaultRequest

If "Yes" has been set to AutoStarUp attribute, the status of a cluster application is automatically transited to Online at RMS startup. Moreover, the status of a standby node is transited to Standby regardless of the Startup attribute of StandbyTransitions.

By contrast, if "No" has been set to the AutoStartUp attribute, the state transition follows the attributes of StandbyTransitions.

The relationship between AutoStartUp and StandbyTransitions is as follows.

RMS Startup node		AutoStartUp=Yes		AutoStartUp=No
		StandbyTransitions		StandbyTransitions
		No	StartUP	No	StartUP
Multiple nodes	Operational side uap	Online	Online	Offline	Standby
Multiple nodes	Standby side uap	Standby	Standby	Offline	Standby
Single node		Standby	Standby	Offline	Standby

Note

To clear the Faulted state of a cluster application and to start it normally in the Standby state when restarting a node after a cluster application is in the Faulted state, set "0(no)" to the PersistentFault attribute.

How to set scalable cluster applications for preventing timeout of Controller resource during a state transition

When it takes time to start up and stop a cluster application that constitutes a scalable configuration, a timeout error of the Controller resource (resource to indicate the scalability) may occur during a state transition. In this case, the state transition is stopped forcibly.

In this case, the setting of Controller resource needs to be changed according to the startup and stop times for each cluster application that constitutes a scalable configuration.

Calculate the Timeout value of a scalable cluster application, and then change its setting with the following procedure:

Procedure

Calculating the maximum state transition time for a cluster application
The status of the Controller resource is transited to Online when the statues of userApplications under the Controller resource are all Online. Therefore, calculate the total values of ScriptTimeouts for each resource that configures a cluster application.
For example, if every one of the following resource; Cmdline resource, Fsystem resource, GDS resource, or Gls resource exist under the cluster application, you can calculate as follows. (The timeout value for each resource is a default value.)
Cmdline resource 300 (sec) + Fsystem resource 180 (sec) + GDS resource 1800 (sec) + Gls resource 60 (sec) = 2340 (sec)
This value is larger than the default value for the scalable cluster application 180 (sec), set the setting value to 2340 (sec).
Information
Default script timeout values for each resource
```
Cmdline  : 300
Fsystem  : 180
GDS      : 1800
Gls      : 60
```
Considering the number of SysNode
Calculate the considered number of SysNode that configures a cluster application.
The number of SysNode is 1
The value calculated in Step 1 is the value where the number of SysNode is considerate.
The number of SysNode is 2 or larger
Minus 1 from the number of SysNode and double the value. Then, multiply it by the one calculated in Step 1.
```
The maximum state transition time of a cluster application between multiple nodes
```
```
= "1) value" x 2 ( "the number of SysNode" -1 )
```
Example
For example, in the case Online or Offline processing of a userApplication is assumed to be finished just before it times out when the userApplication is with a three-node configuration and the status is Online on Node1, after starting the state transition on the first Node, it takes 4 times (2 x ("the number of Sysnode" - 1) for the userApplication to be Online on the final node as follows:
1. Offline processing on Node1
2. Online processing on Node2
3. Offline processing on Node2
4. Online processing on Node3
Calculating the total values of Step 2 for each cluster application
Changing the setting with the hvw command
Follow the procedure below:
1. Start up RMS Wizard with the hvw command.
2. Select "Application-Create" from "Main configuration menu."
3. Select "Controller" from "Application selection menu."
4. Select "Controllers" from "Settings of application type."
5. Select "SELECTED."
6. Select "TIMEOUT(T)" from "Set *global* flags for all scalable (sub) applications."
7. Select "FREECHOICE" and enter the setting value (when entering 2340).
8. Select "SAVE+RETURN" from "Set *global* flags for all scalable (sub) applications."
9. Select "SAVE+EXIT" from "Settings of application type."
See
For detailed operation on how to change RMS Wizard and attributes, see "8.1 Changing the Cluster Configuration" or "PRIMECLUSTER Reliant Monitor Services (RMS) with Wizard Tools Configuration and Administration Guide."

How to stop a standby operational system preferentially in the event of a heartbeat error

When a heartbeat error is detected, set the survival priority for the node to be stopped forcibly so that it prevents all operational and standby systems from being failed by forcibly stopping both operational and standby systems mutually. Below describes how to stop the operational system preferentially and collect the information for investigation.

Note

The weighting of each node to set in the Shutdown Facility is defined to a node.
If an operational and standby system is switched due to a failover or switchover, it cannot be enabled even though the setting is changed. As before, stop an operational system forcibly after a given time has elapsed in a standby system.
When a cluster is switched, be sure to perform a failback.
If a system panic, CPU load, or I/O load continues, it seems like a heartbeat has an error. In this case, the cluster node with an error is forcibly stopped regardless of the survival priority.
A standby system with a low survival priority waits until an operational system is forcibly stopped completely. During this waiting time, if the heartbeat is recovered, some information for investigating the heartbeat error may not be collected.
This case may occur when the CPU load or I/O load is the high in an operational system.

Procedure: Below indicates an example when the operational system is node1, and the standby system is node2.
Note
Perform the Steps 1 to 4 in the both operational and standby systems.

Modify the SF configuration (/etc/opt/SMAW/SMAWsf/rcsd.cfg) for the standby system (node2) with the vi editor, and so on to give a higher weight value to the standby system. Change the weight attribute value of node2 from "1" to "2."
```
node2# vi /etc/opt/SMAW/SMAWsf/rcsd.cfg
```
[Before edit]
```
node1,weight=1,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20
node2,weight=1,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20
```
[After edit]
```
node1,weight=1,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20
node2,weight=2,admIP=x.x.x.x:agent=SA_xx,timeout=20:agent=SA_yy:timeout=20
```
Note
- Describe the setting of one node with one line in the rcsd.cfg file.
- admIP may not be described depending on the version of PRIMECLUSTER.
Restart the SF with the sdtool -r command.
It takes about five seconds to execute the sdtool -r command. After that, the changed SF configuration is reflected to the SF.
```
node2# sdtool -r
```

Use the sdtool -C command. to check that the changed SF configuration has been reflected

Check that the weight attribute value of node2 has become "2."

node2# sdtool -C

Cluster Host   Type    Weight  Admin IP        Agent List (Agent:timeout)
------------   -----   ------  --------        --------------------------
node1          CORE    1       x.x.x.x         SA_xx:20,SA_yy:20
node2          CORE    2       x.x.x.x         SA_xx:20,SA_yy:20

Note

"Type" may not be displayed depending on the version of PRIMECLUSTER.

Use the sdtool -s command to check that all the SAs defined to the SF operate properly. Moreover, check that "Test State" and "Init State" have been changed to "TestWorked" and "InitWorked respectively.

node2# sdtool -s
Cluster Host    Agent         SA State      Shut State  Test State  Init State
------------    -----         --------      ----------  ----------  ----------
node1           SA_xx         Idle          Unknown     TestWorked  InitWorked
node1           SA_yy         Idle          Unknown     TestWorked  InitWorked
node2           SA_xx         Idle          Unknown     TestWorked  InitWorked
node2           SA_yy         Idle          Unknown     TestWorked  InitWorked

Note

Perform the following Steps 5 to 8 either in the operational or standby system.

Check the ShutdownPriority attribute value of a cluster application (userApplication) with hvutil -W command.
When the ShutdownPriority attribute value is other than "0," perform Steps 6 to 9.
When it is "0," no more setting is required.
```
node1# hvutil -W
4
```
Stop PRIMECLUSTER (RMS).
Note
Note that if you stop PRIMECLUSTER (RMS), the operation is also stopped.
```
node1# hvshut -a
```
Change the ShutdownPriority attribute value of a cluster application (userApplication) to "0." First, start the RMS Wizard.
```
node1# /opt/SMAW/SMAWRrms/bin/hvw -n testconf
```
Note
Change testconf based on your environment.
For details, see "8.5 Changing the Operation Attributes of a userApplication".
1. Select "Application-Edit" from "Main configuration menu."
2. Select the appropriate cluster application (userApplication) to change its configuration in "Application selection menu."
3. Select "Machines+Basics" in "turnkey wizard."
4. Select "ShutdownPriority."
5. Select "FREECHOICE" to enter 0.
6. Select "SAVE+EXIT" in "Machines+Basics."
7. Select "SAVE+EXIT" in "turnkey wizard."
8. Select "RETURN" on "Application selection menu."
9. Select "Configuration-Generate."
10. Select "Configuration-Activate."
Start PRIMECLUSTER (RMS).
```
node1# hvcm -a
```
Note
When a cluster is switched, be sure to perform a failback.

How to stop the operational node forcibly in the event of a subsystem hang

The following event is called a subsystem hang: the cluster does not detect that the operation is stopped (the operation seems normal from the cluster monitoring) because only some I/Os within the operational node have errors and other I/Os operate normally.

In this case, if the node is switched to a standby node, the operation may be restarted. In the event of a subsystem hang, ping may respond properly and you may be able to log in to a node.

When a subsystem hang is detected, stop the operational node with the following method and switch the operation.

If you can log in to a standby node

Stop the operational node from the standby node with the sdtool command.

# sdtool -k node-name

  node-name : CF node name of the operational node

If you cannot log in any node

[PRIMERGY]: Panic the operational node with the NMI switch or keyboard operation in the main device.

[PRIMEQUEST]: Collect dumps of the operational node with Web-UI to stop it.

Note

It is possible to determine a subsystem hang from application failures to control a forcible stop mentioned above. In the case, it needs to be determined from multiple clients. That is, even though an error is found from one client, the error may be in the client or on the network. You need to consider such a case when controlling a forcible stop.