Performing SAP postinstallation steps for high availability

Edit online

In addition to the postinstallations steps outlined in the SAP Installation Guide, that uses a virtual host name requires you to perform platform-specific manual steps to ensure correct DB2® connection failover for ABAP work processes to a standby Db2 data sharing member.

Update the db2dsdriver.cfg configuration file

When using CLI failover and virtual host names for your SAP application servers, you need to adapt the connection profile db2dsdriver.cfg.The SAP installation inserts only standard host names and only one <affinitylist> entry and only one Db2 member into the CLI failover configuration file db2dsdriver.cfg. With this configuration, a database connection failover is not possible.

Therefore, you must adapt the db2dsdriver.cfg file as follows:

  • Replace the application server host names with the virtual host names
  • Insert additional data sharing members in the <alternateserverlist> section
  • Define additional entries in the <affinitylist> section and define failover sequences in the serverorder parameters
  • Assign the affinity lists to your application servers virtual host names.

These changes can be made by using the SAP provided Failover Configuration Tool in SAP transaction DBACOCKPIT. The tool ensures the syntactical correctness of the changes and can activate the new CLI failover configuration.

If you choose to adapt the file on the operating system level, you should validate your changes by using the validate option of the db2cli utility that is part of the Db2® CLI driver. After successful validation you need to activate the changes.

Install SAP application server on different physical machines and define redundant services

For availability reasons you should have at least two application server instances installed:

  1. A primary application server (PAS)
  2. An additional application server (AAS) on another physical machine

The profile parameters of the additional application server instances must be configured manually so that all SAP ABAP services that run on the PAS installation are also on it. These are:

  • Batch service
  • Update/Update 2 service
  • Spool service

Through this setup, all non-unique SAP services that are run on each of the application servers and therefore no longer constitute single points of failure (SPOF).

To ensure redundancy from the SAP user perspective you must configure the SAP logon groups.

Adapt the Java property ms.reconnect.timeout

By default, a Java™ application server stops and restarts if it can reconnect to the Java message server within three minutes. Three minutes is the default value of the property ms.reconnect.timeout. For more details, see the SAP online help library:

https://help.sap.com

or see SAP Note 1121900: Message server reconnect parameter optimization - AS Java 7.1. This SAP Note also applies to Java application servers 7.2 and higher.

In order to not restart the Java application server in case of an LPAR loss, you should use a minimum value of 540000 (milliseconds) for ms.reconnect.timeout, which is nine minutes if you run your z/OS® with shared CPs. Use a minimum of 300000 (five minutes) for dedicated CPs. These values take into account two times the default time of z/OS spin loop detection and grant time for SA z/OS to restart z/OS UNIX resources after an LPAR is lost.

Modify SAP Profiles

Enter the following into DEFAULT.PFL or into each application server instance profile: 
enque/con_retries = 120
enque/deque_wait_answer = TRUE
enque/sync_dequeall = 1

Starting with SAP 7.10 it is no longer necessary to explicitly set the profile parameter for the enqueue replication port:

enque/encni/repl_port

Use this parameter only if the replication port of the enqueue server cannot be set to the default port 5XX16 (where XX is the instance number).