Attributes in this section can be changed by users who use the Wizard GUI or hvw command.
Possible Values: 0, 1
Valid for resource objects. If set to 1, executes the online script for an object if the object becomes faulted while in an Online state. If the object is able to return to the Online state, the fault is recovered.
This attribute must be 0 for Controller and controller objects: RMS handles switchover of child applications automatically.
Possible Values: yes, no
Valid for userApplication objects. If set to "yes," automatically brings the application Online when RMS is started.
You can override the AutoStartUp attribute for all userApplication objects by setting the HV_AUTOSTARTUP variable. See the description of HV_AUTOSTARTUP in the "E.3 Local environment variables".
Possible Values: Valid string containing one or more of the following: No, HostFailure, ResourceFailure, ShutDown
Valid for userApplication objects. Configures an application for automatic switchover if it becomes faulted. The values can be combined using the vertical bar ("|") character. The No value inhibits automatic switchover and cannot be combined with any other value.
For backward compatibility, the numeric values 0 and 1 are accepted: 0 is equivalent to No, and 1 is equivalent to HostFailure | ResourceFailure | ShutDown.
Possible Values: 0, 1
Valid for resource objects. If set to 1, guarantees that the resource is online on only one node in the cluster at any time. If set to 0, allows a resource to be online on more than one node at a time. Note that "online" in this context refers to any phase of online processing. For instance, if a resource is in the Online state on one node while its PreOnlineScript is executing on another node, then both resource objects would be considered as online for the purposes of this test.
The user can modify this attribute for Cmdline subapplications only. The configuration tools control this attribute for all other subapplications.
Possible Values: Valid script (character)
Valid for all object types. Specifies a script to be run if the associated object enters the Faulted state.
The argument specified during registration of script will be specified as it is during execution of script.
Wait until this script finishes in the Fault processing.
If the script returns with an exit code value other than zero, the message indicating script failure will be recorded in switchlog file but the Fault processing continues.
For details about Fault processing, refer to "2.1.5 Fault processing".
Possible Values: no(0), yes(1)
Valid for userApplication objects. Controls local node elimination in the event of a double fault. A double fault occurs when a second fault is generated during the initial fault processing of an application.
If HaltFlag is set to yes, and another node is available to run the application, a double fault will trigger the following sequence of events:
First, RMS on the local node will exit immediately.
Next, RMS on another node will invoke the Shutdown Facility to eliminate the local node.
Finally, all applications that were online on the local node, and that have their AutoSwitchOver parameter set to include HostFailure, will be switched over to the available node.
Note
Even if all the conditions for the HaltFlag attribute are met for an application (AutoSwitchOver setting, additional hosts available), other applications running on the same host may block the HaltFlag operation. For instance, another application may have no other available hosts, or it may not have the appropriate AutoSwitchOver setting. In either case, RMS will continue to run on the local node. To prevent this, allocate additional hosts for the other applications and adjust their priority lists to minimize node conflicts with the application that has its HaltFlag attribute set.
Possible Values: 0, 1
Valid for all resource objects. If set to 1, allows the resource to remain Online during Offline processing.
Possible Values: 0, 1
Valid for resource objects. If set to 1, the userApplication does not become Faulted and a switchover does not occur even if the resource becomes Faulted.
However, if the resource becomes Faulted during the Offline processing due to a switchover, the userApplication becomes Faulted even when this attribute is set to 1. Thus, when HaltFlag is set to yes for the userApplication, the Faulted node will be forcibly stopped and remain switched.
When moving from the previous version, setting the MonitorOnly attribute to 0 is recommended. When the value is set to 0, the cluster can be switched even if the Offline processing of the Fsystem resource fails during the Offline processing due to a resource failure or manual switchover.
Possible Values: Valid script (character)
Valid for userApplication objects. Specifies the script to be run after the Offline processing of userApplication has completed.
The argument specified during registration of script will be specified as it is during execution of script.
Do not wait for this script to finish in the Offline processing.
If the script returns with an exit code value other than zero, the message indicating script failure will be recorded in switchlog file but the Offline processing continues.
For details about Offline processing, refer to "2.1.4 Offline processing".
Possible Values: Valid script (character)
Valid for all object types except SysNode objects. Specifies the script to be run to bring the associated resource to the Offline state.
Possible Values: 0, 1
Valid for userApplication objects. Allows RMS to start the application on the node where it was last online when the entire cluster was brought down and then restarted. If set to 0 or not set (the default), the application comes online on the node with the highest priority in the attribute PriorityList. If set to 1, the application comes online on the node where it was last online. In case of AutoStartUp or a priority switch, this last-online node has the highest priority, regardless of its position in the priority list.
RMS keeps track of where the application was last online by means of timestamps. The node which has the latest timestamp for an application is the node on which the application will go online. Different cluster nodes should be in time-synchronization with each other, but this is not always the case.
Since RMS does not provide a mechanism for ensuring time-synchronization between the nodes in the cluster, this responsibility is left to the system administrator.
If RMS detects a severe time-discrepancy between the nodes in the cluster, an ERROR message is printed to the switchlog. NTPD or CHRONY can be used to establish consistent time across the nodes in the cluster.
Refer to the manual page for xntpd or chronyd for more information.
When executing [Configuration-Activate] with the hvw command, the information indicating the node where the cluster application was last online will be cleared.
Possible Values: Valid script (character)
Valid for all objects except SysNode objects. Specifies the script to bring the associated resource to the Online or Standby state.
Possible Values: 0, 1
Valid for userApplication objects. Specifies whether or not processes to check that userApplication to be started is already working for all nodes in which userApplication can work are performed at userApplication startup.
If set to 0, then the application can negotiate its online request only when all the nodes where it can possibly run are online.
If set to 1, then the application can negotiate its online request within the current set of online nodes, even if some other nodes (including the application's primary node) are offline or faulted.
Possible Values: 0, 1
Valid for userApplication objects. If set to 1, when RMS is starting, the state of userApplication that stopped last time will be checked. Under any one of the following conditions, the userApplication becomes the Faulted state (InitialFault) right after RMS is started.
The shutdown processing of RMS is not performed.
userApplication is in the Faulted state when RMS is stopped.
If userApplication becomes the Faulted state, remove the cause of this error first, and then, use hvutil -c to clear the Faulted state.
Note
If the PersistentFault attribute is set to 0, the cluster application does not become the Faulted state at RMS startup after a panic reboot of the operating system, such as when an error occurs on the node. In this case, as it is not the Faulted state, this node is accepted as it can be switched or failed back. If the error definitely occurs on all the nodes that constitute the cluster during the Online processing and also a panic reboot of the operating system occurs, the failover may repeat infinitely.
If the PersistentFault attribute is set to 1, the cluster application becomes the Faulted state at RMS startup after a panic reboot of the operating system, such as when an error occurs on the node. Therefore, clear the fault manually. If the application is stopped, start the userApplication.
Possible Values: Valid script (character)
Valid for all objects except SysNode objects. Specifies the script to be run after the state of the associated resource changes to Offline.
Possible Values: Valid script (character)
Valid for all objects except SysNode objects. Specifies the script to be run after the state of the associated object changes to Online or Standby.
The argument specified during registration of script will be specified as it is during execution of script.
Wait until this script finishes in the Online processing.
If the script returns with an exit code value other than zero, the message indicating script failure will be recorded in switchlog file and the Fault processing will start.
For details about Online processing, refer to "2.1.3 Online processing".
Possible Values: Valid script (character)
Valid for userApplication objects. Specifies the script to be run before the start of Online or Standby processing.
The argument specified during registration of script will be specified as it is during execution of script.
If the script returns with an exit code zero, the Online or Standby processing will be started. If the script returns with an exit code value other than zero, the message indicating script failure will be recorded in switchlog file and the Online or Standby processing will not be started.
For details, refer to "2.1.3.2 PreCheckScript".
Possible Values: Valid script (character)
Valid for all objects except SysNode objects. Specifies the script to run before the object is taken to the Offline state.
The argument specified during registration of script will be specified as it is during execution of script.
Wait until this script finishes in the Offline processing.
If the script returns with an exit code value other than zero, the message indicating script failure will be recorded in switchlog file but the Offline processing continues. Fault processing will start after the Offline processing is completed.
For details about Offline processing, refer to "2.1.4 Offline processing".
Possible Values: Valid script (character)
Valid for all objects except SysNode objects. Specifies the script to be run before the associated object is taken to the Online or Standby state.
The argument specified during registration of script will be specified as it is during execution of script.
Wait until this script finishes in the Online processing.
If the script returns with an exit code value other than zero, the message indicating script failure will be recorded in switchlog file and the Fault processing will start.
For details about Online processing, refer to "2.1.3 Online processing".
Possible Values: 0, 1
Valid for userApplication objects. If set to 1, the resources are not to be taken Offline after a fault. Ignored if ResourceFailure is set to AutoSwitchOver.
Possible Values: 0-MAXINT (in seconds) or valid string of the form "timeout_value[:[offline_value][:online_value]]"
Valid for all object types. Specifies the timeout value for all scripts associated with that object in the configuration file. RMS sends a kill signal to the script if the timeout expires.
Specify the offline_value timeout value and the online_value timeout value respectively in this string format.
Possible Values: 0-20
Valid for userApplication objects. ShutdownPriority assigns a weight factor to the application for use by the Shutdown Facility.
When interconnect failures and the resulting concurrent node elimination requests occur, SF calculates the shutdown priority of each subcluster as the sum of the subcluster's SF node weights plus the RMS ShutdownPriority of all online application objects in the subcluster. The optimal subcluster is defined as the fully connected subcluster with the highest weight.
Possible Values: 0, 1
Valid for resource objects. If set to 1, the object performs standby processing on all the nodes where the parent application is supposed to be Offline.
The user can modify this attribute for Cmdline subapplications only. The configuration tools control this attribute for all other subapplications.
Possible Values: StartUp, SwitchRequest, ClearFaultRequest or any combination joined by vertical bars (|)
Valid for userApplication objects. The value specifies when standby processing is initiated for the application object:
StartUp - at startup. This setting is ignored if the real-world application is already online, or if the application object is forced to go online because the AutoStartUp attribute is set.
SwitchRequest - after application switchover, if the application was online before the switchover.
ClearFaultRequest - after a faulted state is cleared with 'hvutil -c'.
Possible Values: Valid script (character)
Valid for resource objects with detector. Specifies the script to be run after the posted state of the associated resource changes to Warning.
