Managing Serviceguard Extension for SAP on Linux (IA64 Integrity and x86_64), April 2009

The file sap.config contains SGeSAP configuration data for all SGeSAP packages of a <SID> It could
for example contain data to start additional remote SAP dialog instances which are not part of the cluster.
Now every time any SGeSAP package (DB, CI,D01..) starts it scans through the sap.config file, finds
the entry for starting a remote SAP dialog instances and starts this. However, if the goal is for only the CI
Instance to start additional remote SAP dialog instances this data can be added to a private
sapCI<SID>.config and therefore only gets read and started when the CI instance is started.
During startup of a package <pkg_name>, Serviceguard Extension for SAP on Linux checks the existence
of SGeSAP global and private configuration files in the following order:
If a sap.conf file exists, it is effective for compatibility reasons.
If a sap<pkg_name>.conf file exists, it will merge and overrule previous files and is effective.
If a sap.config file exists, it will merge and overrule previous files and is effective.
If a sap<pkg_name>.config file exists, it will merge and overrule previous files and is effective.
NOTE: When configuring package specific configuration files sap<pkg_name>.config you will usually
isolate section 1 in a global sap.config file. All other sections should then be applied in the package specific
configuration files sap<pkg_name>.config, excluding the first section.
For example SAP System C11 containing a Central Instance package with Application Server handling
would then have the following Serviceguard Extension for SAP on Linux configuration files:
sap.config - Section 1,3,4 configured
sapciC11.config - Section 2 configured
Optional Step: OS670
The following arrays are used to configure special treatment of Application Servers during package start,
halt or failover.
These Application Servers do not have SAP adoptive computer enabled nor are they part of a Serviceguard
package. However, an event can be triggered to start, stop or restart them together with the package. If any
triggered attempt fails, it doesn't automatically cause failure of the ongoing package operation. The attempts
are considered to be non-critical. In certain setups, it is necessary to free up resources on the failover node
to allow the failover to succeed. Often, this includes stopping less important SAP Systems, perhaps
consolidation or development environments. If any of these instances is a Central Instance, it might be that
there are additional Application Servers belonging to it. Not all of them are necessarily running locally on
the failover node. They can optionally be stopped before the Central Instance gets shut down. This mechanism
replaces the deprecated SERVER_CONSOLIDATION variable and the RM*arrays of earlier SGeSAP versions.
In the ASSID[*]-array specify the SAP System IDs of the instances that should be treated with the
package. Making this a configurable option allows to specify instances that belong to the clustered
SAP components. It also allows specification of different SIDs for less critical SAP applications.
In the ASHOST[*]-array, refer to the hosts on which the instances reside - this can be either inside
or outside of the cluster.
The ASNAME[*]-array holds the instance names. These names are built by the abbreviations of the
services that are offered by the Application Server. The name of a Dialog instance usually is D, the
name of a Central Instance often is DVEBMGS.
The ASNR[*]-array contains the instance IDs. If the corresponding ASHOST-entry specifies a host
that is part of the cluster, be sure to provide an ID that is different from the IDs used by any packaged
instance. You should also make sure that there is no other SAP instance on the same host is using that
ID.
The ASTREAT[*]-array defines the way the instance is treated if the status of the package changes.
There are five different values that may be configured in any combination: START_WITH_PKG,
86 Step-by-Step Cluster Conversion