SGeSAP Files Configuration

Standard Parameters in sap.conf

Open the file /etc/cmcluster/<SID>/sap.conf with a text editor.

SGeSAP performs activities specific to the database you use. Specify the underlying database vendor using the DB parameter. The compatible options are: ORACLE or INFORMIX.

Provide information about the Central Instance that will be protected by a MC/ServiceGuard package. Set the parameter CINR to the Instance ID of your Central Instance.

If you are using the two package concept you can use the DB_RECONNECT functionality that is provided by SAP R/3.

If you want to use DB_RECONNECT with any instance of your SAP R/3 system, you must disable the automatic restart of the Central Instance, type:

CIRESTART=0

Setting this prevents the Central Instance from restarting in the event of a database failover. This means that the Central Instance profiles must be configured to use DB_RECONNECT. Remember that if you want to use DB_RECONNECT with any application server you must use it with the Central Instance, too. A reconnection of the application server to the switched database is only possible if the Central Instance has not been restarted.

The CIRESTART parameter has no meaning with a Central System that is secured by the one package concept and should not be modified. A failure of the database with a one package concept always means that the Central Instance has failed. The Central Instance is always restarted and reconnection of application servers is not allowed. The same conditions apply if you plan to use a two package approach with both packages on the same node all the time. When configuring the DBRECONNECT mechanism follow the appropriate OSS notes 109036, 98051 and 24806

The file sap.conf contains four arrays that describe the additional application servers of your system.

Additional application servers are all application servers that belong to the SAP R/3 system and are different from the Central Instance. Each array has one entry for each application server. This is true whether the application server is running on a node in the cluster or outside of the cluster.

Specify the relocatable hostnames of the database and the Central Instance in the parameters DBRELOC and CIRELOC.

They will be the same if you use the one package concept.

Specify the relocatable hostname in TRANSRELOC, the host from which the mount to the transport directory /usr/sap/trans is initiated. In a multiple SAP R/3 system environment, specify a separate relocatable hostname for TRANSRELOC. In single system environments TRANSRELOC can be set equal DBRELOC.

Specify AS_PSTART=0 if you want the Application Server startup to run sequentially. The default value here is AS_PSTART=1 for parallel startup. Setting AS_PSTART=0 will slow down your total failover time.

Specify SAPOSCOL_STOP=1 if saposcol should be stopped together with each instance that is stopped.

SGeSAP makes sure that the collector only stops if there is no instance of an SAP R/3 system running on the host.

It is possible to failover both packages of the two package concept to the same node.

If both packages try to come up on a single node after a failover at the same time, it is likely that the Central Instance package wants to start up the Central Instance before the database is fully recovered. This would lead to a failure because SAP R/3 cannot connect to the database.

To deal with this situation, there is a loop implemented that polls the database in increasing intervals of time. The startup of the CI package is delayed until the database is reached. After the first poll, the script waits 10 seconds before initiating another one. After the second poll, the waiting time is increased to 20 seconds, and so forth. This continues until the database responds or up to a maximum of DELAY_INTERVALS polling attempts. You can modify DELAY_INTERVALS if you expect long recovery times.

Additional Parameters in sap.conf

Starting with release 3.0.03 additional parameters were introduced. You can add them on an as needed basis to already existing sap.conf files. The sap.functions file and customer.functions of release 3.0.03 or higher works with sap.conf files of previous releases without changing them.

If your setup consists of application servers that are significantly slower than the Central Instance host, it is possible that the Central Instance shuts down before application server shutdown is completed. This can lead to unsafe shutdowns and Instance crash.

To be safe, specify one of the following:

Control the handling of resources.

On 32bit HP-UX, a shared memory shortage can occur if you install more than one instance on a host. Prior to any instance startup the SGeSAP tries to free up unused or unimportant resources to make the startup more likely to succeed. A database package only frees up database related resources, a Central Instance package only removes IPCs belonging to SAP R/3 administrators. Table 2-8 “Resource Handling and the CLEANUP_POLICY Parameter” summarizes how the behavior of SGeSAP is affected by changing the CLEANUP_POLICY parameter:

SERVER_CONSOLIDATION is used to identify the usage of a consolidated system environment that has multiple SAP R/3 systems on the same node.

To enable the handling of shared memory resources and application servers in a consolidated environment, specify:

SERVER_CONSOLIDATION=1

To specify the Dialog instances handling refer to Step Title not available.

Using Database Reconnect and Transaction Reset

Starting with V3.0 of the SGeSAP Integration Scripts you can configure the DB-Reconnect functionality. DB-Reconnect is a feature provided by SAP R/3. It allows SAP R/3 to remain running if the database switches and the Central Instance stays up. DB-Reconnect can be used with the two package concept. Transaction Reset can be used with either the one package or two package concept. Both DB-Reconnect and Transaction Reset can be combined in the two package concept.

SAP R/3 V4.0B kernel patch level 85 introduced the Transaction Reset functionality. It allows additional SAP R/3 application servers to remain running if the Central Instance switches. The first implementation of Transaction Reset was unreliable and caused problems with some SAP R/3 transactions. Use at least kernel patch level 269.

The DB-Reconnect can be different for each application server. If you want to use DB-Reconnect for any application server, the Central Instance must also be configured to reconnect. Make sure that the data remains consistent under all conditions. If the Central Instance fails, all application servers are always restarted.

If you want to use the DB-Reconnect functionality:

Add entries to:

When configuring the DBRECONNECT feature follow the appropriate OSS notes 109036, 98051 and 24806.

For example:

rsdb/reco_trials = 15rsdb/reco_sleep_time = 60rsdb/reco_sosw_for_db = off (based on OSS #109036)rsdb/reco_sync_all_server = on

If you want to use the DB-Reconnect functionality:

Make sure that you configured CIRESTART=0 as described in Step Title not available the default setting of CIRESTART is 0 starting with SGeSAP Release 3.01.

If you want to use the DB-Reconnect functionality:

Use ASTREAT[] values that are <4 for any application server that uses DB-Reconnect.

The ASTREAT[] array defines how the application servers are treated during switchover.

ASHOST[] and ASTREAT[] values with the same index belong to the same application server:

ASTREAT [X] = Y 

where —

X specifies the corresponding application server.

Y is an integer value that defines the way the application server is treated.

Y = 0 means that the application server is not affected by any changes that happen to the package status. At the moment there are three triggers you can use to customize the way the scripts affect the application server. They are:

Table 2-9 “Y Values for ASTREAT[]” provides a summary of values for Y:

The Central Instance is treated the same as any of the additional application servers. Use CIHOST and CIRESTART instead of ASHOST[] and ASTREAT[].

Table 2-10 “ASTREAT Configuration Options” provides an overview of the possible configurations and the corresponding actions.

The Central Instance should always be ACTIVE and configured for FINAL_STOP.

The RECONNECT behavior can be specified.

Advanced Options in sap.conf

In /etc/cmcluster there is a file called customer.functions. Do not change the sap.functions. The customer.functions templates that are delivered with SGeSAP work with additional parameters in the second part of sap.conf. Use the customer.functions as needed.

SAPROUTER is a sample additional program that always starts on the Central Instance host. To start an saprouter on the CI host automatically, specify:

SAPROUTER_START=1

You can also provide an option string that is passed to the saprouter, for example to set the path to the saprouttab file to reside on a shared volume.

Typically, set a maximum of one saprouter inside of the cluster. saprouters cannot share a service port. So make sure that you use different ones, if a failover to the same node is possible for the saprouters.

Sometimes, when a failover occurs, you want to stop other SAP R/3 Instances running on backup nodes.

This is useful if you have to free up limited resources before you are able to start the failed Instance again. You have to configure two groups of arrays to use this functionality:

If there is a special demand to use values different from the default, it is possible to redefine some of the following values:

If you want to use a database different from ORACLE or INFORMIX:

Currently only ORACLE and INFORMIX databases are supported, but there is a mechanism to easily integrate another database, provided its handling is not significantly different.

Specify a database vendor different from ORACLE and INFORMIX in the DB parameter of sap.conf: DB=<VENDOR>

SGeSAP Integration calls the script functions:

start_<VENDOR>_db, stop_<VENDOR>_db, and stop_<VENDOR>_as

These functions start and stop the database as well as stop an application server gracefully. The third function is needed, in case there are specific tasks required to stop an application server after the underlying database has failed. These functions must be specified in the database dependent part of the customer.functions file.

Configuring an Application Server Package with SGeSAP

The configuration of an application server package introduces some advantages for SAP application servers. As described in Chapter 1, an application server package has advantages within a 2 node cluster configuration with symmetric nodes or when protecting dedicated batch servers within a cluster. The following intallation step describes the generic setup of an application server package.

The APP-package should be called ap<SID><INSTNR> according to the conventions shown in the following table.

# cmmakepkg -p /etc/cmcluster/<SID>/ap<SID><INSTNR>.conf

# cmmakepkg -s /etc/cmcluster/<SID>/ap<SID><INSTNR>.cntl

ap<SID><INSTNR>

# cp /opt/cmcluster/SID/sapap.cntl /etc/cmcluster/<SID>

See IS377.

ASTREAT[@]=2: halt the application server package after switching of ci- or dbci-package (in ap<SID><INSTNR>.conf set AUTO_RUN to NO)

ASTREAT[@]=1: start the application server package when starting the dbci- or ci-package (in ap<SID><INSTNR>.conf set AUTO_RUN to NO)

ASTREAT[@]=0: start/halting/switching is controlled by the cluster management, the dbci- or ci-package related to the application server package is not controlling the application server package (in ap<SID><INSTNR>.conf set AUTO_RUN to YES).

Your application server package has now been configured completely. Remove the "debug" file and restart the package to see whether the SAP application server comes up correctly on all nodes configured.

SGeSAP configuration for SCM High Availability - APO/LiveCache

Configuring a HA LiveCache system requires some additional task that differ from a standard R/3 configuration. The APO system itself can be treated as an additional SAP R/3 system and therefore can be configured in SGeSAP using the standard installation steps.For the setup of LiveCache on SGeSAP it is required to follow the attached special installation steps for LiveCache. These steps are based on the SAP documentation "LiveCache and High Availability on Unix platforms" and "Backup and recovery for APO 3.0". It is recommended to read these documents before proceeding with the SGeSAP configuration of LiveCache.

It is required to follow the listed SAP OSS notes appropriately: 383312, 383468, 154997, 111865.

Customization control/config files.

The LiveCache is configured similar to a standard db-package. Execute the following steps for the configuration of a LiveCache package in the appropriate order:

Customize sap.conf. Customize sap.conf appropriately. Only the following parameters in sap.conf are relevant to set for a LiveCache package:

The strict option should be set in order to guarantee the LiveCache package gets all resources required on the adoptive node. Remember that this option can crash a system running on the adoptive node.

RMNR[0]=<SYSTEMNUMBER>;RMDEP[0]=0 ;RMADM[0]=<SID>admRMDEPNR[0]=<SYSTEMNUMBER>;RMDEPHOST[0]=<adoptive_node>;RMDEPPLATFORM=HP-UXRMDEPNR[1]=-1

See the examples given in sap.conf for more details on how to set this array.

Set up for LiveCache Monitor

SAP recommends the use of a monitor in order to test the availability of LiveCache periodically. This monitor periodically checks the availability of the LiveCache system. If the monitor recognizes the LiveCache to be unavailable, it will try to restart LiveCache several times on the node it is currently running. It will switch the package when the LiveCache is still unavailable.

The monitor program is shipped with SGeSAP in the saplc.mon file. Follow the attached steps on how to integrate the monitor into the LiveCache package configuration. The monitor actually runs as a Servcice attached to a MC/ServiceGuard package. Find additional information about services in MC/ServiceGuard environments in the "Managing MC/ServiceGuard" documentation.

Service configuration

Configure Service ]<SID> for the monitor in file /etc/cmcluster/<SID>/lc.conf:

Refer to the comments in the configuration and control files to get more information about setting the parameters appropriately. The examples show reasonable values. The SERVICE_RESTART[0] parameter sets the number of restarts MC/ServiceGuard will try to restart the service on the node it was running. When this number is met the MC/ServiceGuard will switch the package to the adoptive node. The number of the actual service restarts can be found when executing "cmviewcl -v".The monitor can be paused/resumed by placing/removing a lc.debug file in /etc/cmcluster/<SID>. This is helpful when configuring LiveCache and running the LiveCache package in debug-mode.The file /sapdb/LHP/db/sap/lccluster is used by the LiveCache program lcinit to indicate that the LiveCache is running in a cluster environment.

Configure LiveCacheLiveCache need to be aware it is running in a cluster environment. Therefore several configurations are required.

LiveCache Configuration

Volumegroups and filesystemsThe LiveCache dev-spaces (data, log, system) need to be placed on the MC/ServiceGuard-shared disks. Usually these dev-spaces are placed on rawdevices. Additionally /sapdb/programs and /sapdb/data need to be on shared devices. See attached table for more information about the volumegroup needed for the LiveCache:

Table 2-12 Title not available (LiveCache Configuration)

LiveCache package	VG Name	lvol Names	Mount Point Usage	Device Number
lc<SID>	vg<SID>	rlvLHP1	raw - data1	06
		rlvLHP2	raw - data 2
		rlvLHP3	raw - data 3
		rlvLOG	raw - log
		lvSYS	/sapdb/<SID>/dbsys
		lvSAPDB	/sapdb

 

Cluster node synchronization

• Synchronize /usr/spool/sql recursively to the adoptive node:

• Synchronize the following ports to /etc/services:

• sql30 7200/tcp

• sql6 7210/tcp

• Synchronize /etc/passwd with the <SID>adm

• Synchronize /etc/group with group "sapsys"

LC Installation Step:

Level: IS556

Configure LiveCache connections within APO:

Running LiveCache within a MC/ServiceGuard cluster package means that the LiveCache instance is now configured for the relocatable IP of the package. This configuration needs to be adopted in the APO system that connects to this LiveCache.

Figure 2-1 “LiveCache Connections Within APO” shows an example for configuring "LCA" to "reloc8".

Figure 2-1 LiveCache Connections Within APO

Run SAP transaction "lc10" and configure the logical LiveCache names "LCA" and "LCD" to listen to the relocatable IP, which the LiveCache-package is running under.

LC Installation Step:

Level: IS557

Configure XUSER file in the APO-user homedirectoryThe XUSER file in the home directory of the APO-user is the file that holds the connection information and grant information for a client connecting to LiveCache. The XUSER content needs to be adopted to the relocatable IP the LiveCache in running on.Run the following commands on every APO-Application server:

# su - <SID>adm(<SID> is there the SID of the APO-system)

# dbmcli -d <LIVECACHE_SID> -n <LC_relocatable_IP> \

-us control,control

To verify that the relocatable IP is in the XUSER file, run the following command as <SID>adm of the APO user:

# dbmcli -ux SAPR3,SAP -ul

You should get output like the following for a relocatable hostname "reloc8" and a physical hostname "hpcc072":

OK

DEFAULT SAPR3

1LHPhpcc072 CONTROL

1LHPreloc8 CONTROL

LC Installation Step:

Level: IS558

Verify LiveCache package setup

Verify your LiveCache installation following the attached steps:

• Touch a /etc/cmcluster/<SID>/debug file and /etc/cmcluster/<SID>/lc.debub file and startup the LiveCache package

• Manually start LiveCache as APO <SID>adm using transaction LC10

• Shutdown LiveCache package

• Remove both debug files

• Startup/shutdown the LiveCache package and check the logfile in /etc/cmcluster/<SID> for consistency

HP Somersault Integration with SGeSAP

HP Somersault was introduced with SAP R/3 Release 4.6B to protect the SPOF enqueue server. HP Somersault is only supported in an MC/ServiceGuard cluster environment. The installation steps described in this section must be followed when enabling HP Somersault with SGeSAP. Refer to Chapter 3, "Chapter 3 “SGeSAP Administration”," for additional information about HP Somersault in SGeSAP.

Configure HPSOM to identify HP Somersault use.

Set HPSOM=1 if HP Somersault is enabled and the SAP R/3 enqueue server is protected by HP Somersault. This is the only parameter to set within SGeSAP that enables HP Somersault. The default value is HPSOM=0.

The environment variable HPSOM_HOME sets the launching or shutdown of HP Somersault. The standard path /var/opt/hpsom/<SID> is automatically set in the SGeSAP environment. Refer to the hidden options section in sap.conf to set a non standard path for HPSOM_HOME.

When HPSOM is set to 1 there are additional parameters to be set in the SAP R/3 profile and standard HP Somersault must be successfully configured. Refer to your HP Somersault documentation.