olar.config(4)olar.config(4)NAME
olar.config, olar.config.common - Online Addition and Removal policy
configuration files
SYNOPSIS
/etc/olar.config - Member-specific automatic deallocation policy con‐
figuration file
/etc/olar.config.common - Cluster-shared automatic deallocation policy
configuration file
DESCRIPTION
The olar.config and olar.config.common files provide user-definable
policy settings that control the behavior of the Automatic Deallocation
Facility. The Automatic Deallocation Facility will attempt to take a
component out of service without user intervention in the event that
the component is identified as being suspect by the component indict‐
ment process. See the OLAR_intro(5) reference page for information on
the component indictment process. The Web-Based Enterprise Service
(WEBES) 4.0 software suite (or higher) is required to be installed to
support component indictment.
By setting specific variables in either the /etc/olar.config or
/etc/olar.config.common file, you can define the conditions for when
automatic deallocation is appropriate. Additionally, you can turn off
automatic deallocation individually for each supported component class,
for example all central processing units (CPUs), if desired. Changes
made to this file take effect immediately. There is no need to restart
or reconfigure any associated daemons.
Automatic deallocation is currently supported on the GS80/GS160/GS320
series systems. CPU modules and memory pages are currently supported
for automatic deallocation on these systems.
By default automatic deallocation policy applies to all members in a
cluster environment. This is specified through the cluster-wide file
/etc/olar.config.common. However, when operating in a cluster environ‐
ment, cluster-wide policy variables can be overridden using the member
specific configuration file /etc/olar.config.
Specifically, these files are used as follows: On a stand-alone system,
policy variables in both /etc/olar.config and /etc/olar.config.common
are used to determine automatic deallocation policy, with attribute
values in /etc/olar.config overriding values set in /etc/olar.con‐
fig.common. In a cluster environment, configuration variables in the
/etc/olar.config.common file are shared by all cluster members. The
/etc/olar.config file is defined as a Context Dependent Symbolic Link
(CDSL) and hence, there is a distinct /etc/olar.config file for each
member in a cluster. The configuration variable settings in any given
/etc/olar.config file provides automatic deallocation policy for that
member only.
When the Automatic Deallocation Facility is invoked as the result of a
component's indictment, it will post the results of its execution,
including specific policy variable evaluation, as one or more Event
Management (EVM) events. This not only provides an audit trail for this
automated process, but also allows user applications to listen for (or
subscribe to) these events if desired. All Automatic Deallocation
Facility EVM events have a prefix of sys.unix.sysman.auto_deallocate.
See the EVM(5) reference page for general information on the EVM facil‐
ity.
You may view the complete list of all possible events that may be
posted, including a description of each event, by issuing the following
command: # evmwatch -i -f '[name sys.unix.sysman.auto_deallocate]' |
evmshow -t "@name" -x | more
POLICY VARIABLES
The following discussion describes the policy variables defined for
automatic deallocation of a CPU. Note that all policy variables are
case insensitive: The cpu_deallocate_allow attribute is used to define
whether or not automatic deallocation is allowed when a CPU is
indicted. If this attribute is left NULL or specified as FALSE, then
there will be no automatic deallocation attempt of hardware components
that belong to the "CPU" class when a CPU is indicted. By default this
value is set to NULL. No other cpu_deallocate* policy variables will
be evaluated if this attribute is not set to 'TRUE'. The cpu_deallo‐
cate_start_time attribute denotes the time (in 24 hour format) begin‐
ning with and after which automatic deallocation is allowed. This
attribute is used in conjunction with cpu_deallocate_end_time to spec‐
ify a time window in which automatic deallocation of indicted CPUs can
take place. If no start value is specified, a default value of 00:00 is
used. The cpu_deallocate_end_time attribute denotes the time (in 24
hour format) up to and including when automatic deallocation is
allowed. This attribute is used in conjunction with cpu_deallo‐
cate_start_time to specify a time window in which automatic dealloca‐
tion of indicted CPUs can take place.
The start and end times are allowed to cross a day boundary.
If no end value is specified, a default value of 23:59 is used.
The cpu_deallocate_probability attribute refers to the single
indicted probability or list of indicted probabilities for which
automatic deallocation should occur for an indicted CPU. See the
OLAR_intro(5) reference page for additional information on com‐
ponent indictment probabilities.
Probabilities could be any combination of the three discrete
values 'LOW', 'MEDIUM' and 'HIGH'. When specifying multiple
probabilities they must be enclosed in curly braces ( { } ), and
must be delimited by a comma (,). If no value is specified for
this attribute, automatic deallocation will only occur for com‐
ponents indicted with a 'HIGH' probability. The cpu_deallo‐
cate_user_supplied_script attribute describes the full path to a
user-supplied script that you may want to execute prior to auto‐
matic deallocation of an indicted CPU. If present, this script
must: Have execute permission. Be owned by root. Provide a
zero return status to indicate successful execution. A non-zero
return value will prevent the automatic deallocation from pro‐
ceeding.
When the user supplied script is invoked, it is passed two
parameters. The first parameter is the CPU name of the indicted
CPU. The second parameter is the CPU hardware-id of the
indicted CPU. Determines whether automatic deallocation of a
CPU should occur if processes have been bound to run specifi‐
cally on the indicted CPU, or processes have been bound to the
Resource Affinity Domain (RAD) that the CPU belongs to. If the
value of this policy variable is TRUE, the CPU is automatically
removed from use by the operating system even under the follow‐
ing situations: Processes are bound to run specifically on the
CPU. Those bound processes will suspend until the CPU is brought
back to the 'online' state. Processes are bound to the Resource
Affinity Domain (RAD) and the last running CPU in that RAD has
been indicted. Those processes that are bound to the RAD will
suspend execution until any of the CPUs that belong to the RAD
are brought back to the 'online' state.
Conversely, if this policy variable is set to FALSE or left
NULL, an indicted CPU will not be deallocated either if pro‐
cesses are bound to the CPU or if processes are bound to the
RAD of which the indicted CPU is the last running CPU.
Use caution when enabling this option, because allowing certain
applications to suspend may cause unpredicatable behavior. For
information on binding processes to CPUs or to RADs see the
runon(1) and rad_bind_pid(3) reference pages.
The following discussion describes the policy variables defined for
automatic deallocation of a memory page, also known as a page frame
number (PFN): The pfn_deallocate_allow attribute is used to define
whether or not automatic deallocation is allowed when a memory page is
indicted. If this attribute is left NULL or specified as FALSE, then
there will be no automatic deallocation of memory pages when a memory
page is indicted. By default this value is set to TRUE. No other
pfn_deallocate* policy variables will be evaluated if this attribute is
not set to 'TRUE'. The pfn_deallocate_start_time attribute denotes the
time (in 24 hour format) beginning with and after which automatic deal‐
location is allowed. This attribute is used in conjunction with
pfn_deallocate_end_time to specify a time window in which automatic
deallocation of indicted memory pages can take place. If no start value
is specified, a default value of 00:00 is used. The pfn_deallo‐
cate_end_time attribute denotes the time (in 24 hour format) up to and
including which automatic deallocation is allowed. This attribute is
used in conjunction with pfn_deallocate_start_time to denote a time
window in which automatic deallocation of indicted memory pages can
take place. The start and end times are allowed to cross a day bound‐
ary. If no end value is specified, a default value of 23:59 is used.
The pfn_deallocate_probability attribute refers to the single indicted
probability or list of indicted probabilities for which automatic deal‐
location should occur for an indicted memory page.
Probabilities could be any combination of the three discrete
values 'LOW', 'MEDIUM', and 'HIGH '. When specifying multiple
probabilities they must be enclosed in curly braces ( { } ), and
must be delimited by a comma (,). If no value is specified for
this attribute, automatic deallocation will only occur for mem‐
ory pages indicted with a 'HIGH' probability. The pfn_deallo‐
cate_user_supplied_script attribute defines a full path to a
user-supplied script that you may want to execute prior to auto‐
matic deallocation of an indicted PFN. The script is started
with a parameter that can be used in the script, the decimal
value of the PFN. If present, this script must: Have execute
permission. Be owned by root. Provide a zero return status to
indicate successful execution. A non-zero return value will
prevent the automatic deallocation from proceeding.
RESTRICTIONS
The automatic deallocation facility is only supported on the GS80,
GS160, and GS320 series systems.
EXAMPLES
This example sets the policy variables cpu_deallocate_start_time and
cpu_deallocate_end_time, to define a time window in which CPU automatic
deallocations are allowed in the event that a CPU module had been
indicted.
cpu_deallocate_start_time=22:00
cpu_deallocate_end_time=05:00
Note that start and end times cross a day boundary. This exam‐
ple sets the policy variable pfn_deallocate_probability to allow
a memory page deallocation when the associate memory page has
been indicted with either a medium or high probability.
pfn_deallocate_probability={MEDIUM,HIGH} This example sets the
policy variable cpu_deallocate_user_supplied_script to the full
path name of a user-supplied script to be executed each time a
CPU module is indicted.
cpu_deallocate_user_sup‐
plied_script=/usr/users/las/bin/myScript.sh
ERRORS
If there is an error in any of the policy values, the automatic deallo‐
cation utility will not deallocate the indicted component or memory
page. If all policy variables were evaluated successfully, but there
was an error when attempting to complete the automatic deallocation, an
associated EVM event will be posted detailing the error.
FILESSEE ALSO
Commands: hwmgr(8), sysman_menu(8), sysman_station(8)
Others: OLAR_intro(5)olar.config(4)