olar.config.common man page on OSF1

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
OSF1 logo
[printable version]

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.

FILES
SEE ALSO
       Commands: hwmgr(8), sysman_menu(8), sysman_station(8)

       Others: OLAR_intro(5)

								olar.config(4)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net