# IBM_PROLOG_BEGIN_TAG # This is an automatically generated prolog. # # # # Licensed Materials - Property of IBM # # (C) COPYRIGHT International Business Machines Corp. 2001,2019 # All Rights Reserved # # US Government Users Restricted Rights - Use, duplication or # disclosure restricted by GSA ADP Schedule Contract with IBM Corp. # # IBM_PROLOG_END_TAG ************************************************************************ rsct.compat.basic ************************************************************************ # sccsid = "@(#)63 1.4 src/rsct/rsct.compat.basic.README, clpkg.rsct, rsct_rady, rady2035a 11/12/15 16:44:30" DESCRIPTION The rsct.compat.basic file sets include availability infrastructure provided by RSCT Event Management. INSTALLATION INFORMATION The RS/6000 Cluster Technology (RSCT) requires the installation of the perfagent.tools file set. This requirement is enforced by having a corequisite in the rsct.compat.basic.rte file set on the perfagent.tools file set. The perfagent.tools file set is shipped with AIX. Refer to the PSSP Installation and Migration Guide or the HACMP/ES Installation and Administration Guide for more information. When installing PSSP 3.1 or later releases, the installation of RSCT is a co-requisite. If the system already has installed a prior version of PSSP, the previous Event Management configuration file, /usr/lpp/ssp/install/config/haemloadlist, will be moved to the installation configuration save directory, /usr/lpp/save.config. If modifications had been made to the previous haemloadlist file, such modifications must be placed in a customer created file, and a new Event Management Configuration Database (EMCDB) created. Please refer to the Event Management Subsystem chapter of the PSSP Administration Guide for more information regarding the haemloadlist file, EMCDB, and modification instructions. Note that the Event Management configuration data is now contained in the /opt/rsct/install/config/haemloadlist file. ADVISORIES The following restrictions must be observed for this release of the Event Management Subsystem: Structured Byte Strings may not be more than 1024 bytes in length. Except for certain resource variables provided by IBM, all resource variables must define the rvLocator attribute to be the name of one of the elements in the associated resource ID. If a PTX name is defined for a resource variable, the total length of the PTX name, as it is formed by the Event Management Subsystem, must conform to the following limits (refer to the Event Management Configuration Data Reference chapter in the RSCT Event Management Programming Guide and Reference for PTX name formation): - The length of the name, consisting of all components but the last, must not exceed 63 bytes. - The length of the last component of the name must not exceed 31 bytes. The length of any possible resource ID element value that is substituted into the PTX name must be used in determining this length. A client running on a control workstation can only establish Event Management sessions with partitions managed by that control workstation. DOCUMENTATION UPDATES AND INFORMATION Considerations for Network Information Service (NIS) This section only pertains to machines, SP nodes or SP control workstations, running Network Information Services (NIS). See the "Network Information Service" chapter of "AIX Version 4.3 System Management Guide: Communications and Networks", SC23-4127, for detailed information about NIS administrative procedures. If you are using NIS on your SP nodes, or on the SP system's Control Workstation, you may have to perform NIS related procedures after performing some operations with the rsct.basic control scripts. These scripts are hatsctrl, hagsctrl, and haemctrl. The scripts can be run directly, or can be run indirectly by running the syspar_ctrl command. The script functions that pertain to this discussion are "Adding the Subsystem", "Cleaning Up the Subsystems", and "Unconfiguring the Subsystems", represented by the -a, -c, and -u flags, respectively. For this discussion, the interesting feature of these functions is that they modify the /etc/services file. This is significant on machines running NIS, because NIS manages a map, the NIS services map, that is generated from the /etc/services file on the NIS master server. Furthermore, this map is referenced by clients of the NIS domain served by the NIS master server. The control scripts only modify the local /etc/services file on the machine on which they are being run. They do not modify the NIS services map. To understand the implications of this, it is helpful to review how the role of the local /etc/services file changes when running NIS. On a machine that is not a NIS client, the contents of the local /etc/services file unquestionably affects the results obtained by calls to the library routines getservbyname() and getservbyport(). These library routines simply look in the local file for the first entry that matches the criteria specified on the call. On an AIX machine that is a NIS client, the contents of the local /etc/services file may still affect the results obtained by calls to getservbyname() and getservbyport(). However, the contents of the NIS services map plays a larger role. In this case, the library routines first send a request to the NIS server process running on a NIS server (which may or may not be the same machine as the NIS client). If the NIS server finds a match in the services map, that information is returned to the routine's caller. If the NIS server does not find a match, the library routine searches the local /etc/services file for a match. The rsct.basic daemons depend on the information placed in the /etc/services file by the control scripts for correct operation. These daemons call getservbyname() to obtain information about ports to be used for communications. On a NIS client, the correct information will be obtained by a daemon if the NIS services map does not contain an entry for the service name queried by the daemon, or if the NIS services map contains an identical entry to what the daemon's control script has put in the local /etc/services file. If the information in the NIS map conflicts with the information in the local /etc/services file, the daemon may not function correctly. What should a prudent NIS system administrator do? After running rsct.basic control scripts with the -a flag, it would be a good idea to update the NIS services map on the NIS master server and update any NIS slave servers with the new map. If your NIS master server is not the control workstation, this may involve manually copying entries placed in the control workstation's /etc/services file by the rsct.basic control scripts into the NIS master server's /etc/services file before updating the NIS services map. After running the rsct.basic control script with the -c or -u flags, it would be a good idea to update the NIS services map on the NIS master server and update any NIS slave servers with the new map. If your NIS master server is not the control workstation, this may involve manually removing entries from the NIS master server's /etc/services file before updating the NIS services map. The entries placed in the /etc/services file by the rsct.basic control scripts have the service names hats., hags., haem., and haemd. If running a rsct.basic control script with the -a flag yields an error message indicating that a service name cannot be registered, and examination of the local /etc/services file does not explain the problem, the NIS services map may be out of sync with the file. The NIS services map can be examined with the "ypcat services" command. If the contents of the NIS services map explains the problem, you may have to update the NIS services map before attempting to run the control script again. Limitations on the Number of Resource Variable Instances The Event Management subsystem now limits the number of resource variable instances, for resource variables of value type Counter or Quantity, that can be registered by a resource monitor on each node of a RS/6000 SP, including the Control Workstation, or of a HACMP/ES cluster. This limitation is applied on a resource class basis. In other words, if a resource monitor supplies resource variables in two classes, or two resource monitors each supply variables in one class, each class has a limit of 10000 resource variable instances. The RMAPI does not return an error if this limit is exceeded, since the limitation applies only to the Event Management subsystem. Resource variable instances registered in excess of 10000 are still available to Performance Toolbox Parallel Extensions (PTPE) via the RMAPI. The first 10000 resource variable instances registered by a resource monitor in a resource class are accepted by the Event Manager daemon. Any instances beyond this limit are silently ignored. In this release, the only subsystem that can supply this many resource variable instances is the Virtual Shared Disk (VSD) subsystem. The limit value of 10000 is the default. It can be lowered but it cannot be raised. The limit may be lowered if several resource classes each have resource variable instances that number close to the limit and the CPU utilization of the Event Management daemon on any node becomes unacceptable. The limit can be lowered on a class-by-class basis by specifying a new attribute on the definition of a resource variable class, as found in the load list file containing the class definition. See the Event Management Subsystem chapter of the PSSP Administration Guide for information regarding the procedure for accomplishing this task. Note that that limit cannot be changed in a HACMP/ES cluster. Considerations for Event Management responsiveness to Group Services Group Services will "ping" the Event Management daemon every 2 minutes. The Event Management daemon must respond to Group Services within 2 minutes, or Group Services considers the Event Management daemon non-responsive. The Event Management daemon that is marked as non-responsive will eventually exit. New environment variables have been introduced to modify these setting. These environment variables should be used with caution. Changing these values will affect the ability of the system to identify responsiveness issues with the Event Management daemon. EM_GSI_RESP_INTERVAL: The value in seconds for the interval at which Group Services will "ping" the Event Management daemon. EM_GSI_RESP_LIMIT: The number of seconds in which the Event Management daemon must respond to Group Services. The default and lowest value for each variable is 120. The maximum value for each variable it 1800.