SAP R/3 System Configuration

Logon as <sid>adm on the primary node on which the Central Instance has been installed. The appropriate MC/ServiceGuard package should still run on this host in debug mode.

Change into the profile directory by typing the alias:

cdpro

In the DEFAULT.PFL change the following entries and replace the hostname with the relocatable name. For example:

SAPDBHOST = <relocdb> 
rdisp/mshost = <relocci> 
rdisp/sna_gateway = <relocci> 
rdisp/vbname = <relocci>_<SID>_<instnr> 
rdisp/enqname = <relocci>_<SID>_<instnr> 
rdisp/btcname = <relocci>_<SID>_<instnr> 
rslg/collect_daemon/host = <relocci> 

The following parameters are only necessary if an application server is installed on the adoptive node. For example:

rslg/send_daemon/listen port 
rslg/collect_daemon/listen port 
rslg/collect_daemon/talk port 

	NOTE: If you are using the one package concept use <relocdbci> instead of <relocdb> or <relocci>. Never use server LAN addresses for any of these parameters.

In the <SID>_DVEBMGS<INSTNR> profile add or modify the following entries:

SAPLOCALHOST = <relocci>
SAPLOCALHOSTFULL = <relocci>.<domain> 

Because we are using relocatable IP addresses for SAP R/3 services, the SAP R/3 profile parameters SAPLOCALHOST and SAPLOCALHOSTFULL are very important for SAP R/3 operations.

	NOTE: The profile name is sometimes extended by the hostname. You do not need to change this filename to include the relocatable hostname.

SAPLOCALHOST is set to the hostname per default at startup time and is used to build the SAP R/3 application server name:

<SAPLOCALHOST>_<SID>_<INSTNR>

This parameter represents the communication path inside an SAP R/3 system and between different SAP R/3 systems. SAPLOCALHOSTFULL is used for rfc-connections. Set it to the fully qualified hostname.

The application server name appears in the server list held by the message server, which contains all instances, hosts and services of the instances. The application server name or the hostname is also stored in some system tables on the database.

When using the default addressing scheme for the application server name, this name changes during a failover to another node because the backup node has a different hostname than the primary node. This creates a need to cleanup ABAP code similar to the processes required in version 1.0 of the SGeSAP Integration scripts.

When setting the SAPLOCALHOST parameter to the name associated with the relocatable IP address - which moves with the package to the other node - the application server name stays the same after a switchover. This enables all services which make use of the application server name to continue working after a switchover without any change.

The name of a relocatable IP address is also used to specify the SAPDBHOST. This is different from the standard setup with previous SGeSAP Integration versions.

The parameter SAPLOCALHOSTFULL must be set even if you do not use DNS. In this case you should set it to the name without the domain name:

SAPLOCALHOSTFULL=<relocci>

If you use a SAP R/3 release prior to 3.1H:

Add the following entry to DEFAULT.PFL:

gw/netstat =/usr/bin/netstat -in | cut -c 29- 

Starting with SAP R/3 releases 4.5 TPPARAM has been replaced by 2 new transport configuration files: DOMAIN.CFG and TP_DOMAIN_<SID>.PFLModify the dbhost entries appropriately.

In the file /usr/sap/trans/bin/TPPARAM, modify the dbhost entry as follows:

<SID>/dbhost = <relocdb>

If you have already received your licenses from SAP R/3 install them on all the nodes where the Central Instance can start. Refer to the MC/ServiceGuard Extension for SAP R/3 Release Notes for further information on how to do this. The package comes up without a license, too. But certain restrictions apply to the SAP R/3 application. A warning is printed into the package log-file.

SAP R/3 will now be ready to run on all cluster nodes. Test the manual startup on all adoptive nodes.

Switch the packages to the adoptive nodes with debug mode still enabled.

Start SAP R/3 as <sid>adm on the adoptive nodes manually. You should end up with SAP R/3 running on any cluster node.

On all cluster nodes, remove the file /etc/cmcluster/debug.

Connect with a SAPGUI. Import the changed SAP R/3 profiles within SAP R/3. The transaction is called RZ10.

After importing the profiles, check with rsparam in SE38 if the parameters SAPLOCALHOST and SAPLOCALHOSTFULL are correct. If you do not import the profiles, the profiles within SAP R/3 can be edited by the SAP R/3 Administrator. The values listed from SAP R/3 will be wrong and, when saved, will overwrite the values which edited on the HP-UX level.

The destination for print formatting, which is done by a Spool Work process, uses the application server name.

If the application server name stays the same because SAPLOCALHOST has been set to the relocatable name, after a switch no changes need to be done.

Printing works consistently. A print job in process at the time of the failure is canceled and needs to be reissued manually after the failover. To make a spooler highly available on the Central Instance server, set the destination of the printer to <relocci>_<SID>_<INSTNR> using transaction SPAD.

Batch jobs can be scheduled to run on a particular instance.

You select a particular instance by its hostname at the time of job scheduling. The application server name and the hostname retrieved from the Message Server are stored in the Batch control tables TBTCO, TBTCS...

When the batch job is ready to run, the application server name is used to start it on the appropriate instance. When using <relocci> to build the application server name for the SAP R/3 instance, you do not need to change batch jobs, which are tied to the locality, after a switchover, even if the hostname which is also stored in the above tables differs.

Within the SAP R/3 Computing Center Management System (CCMS) you can define operation modes for SAP R/3 instances.

An operation mode defines a resource configuration for the instances in your SAP R/3 system. It can be used to determine which instances are started and stopped, and how the individual services are allocated for each instance in the configuration.

An instance definition for a particular operation mode consist of the number and types of work processes as well as start and instance profiles (starting with version 3.0 the CCMS allows profile maintenance from within SAP R/3).

When defining an instance for an operation mode, enter the hostname and the system number of the application server. By using <relocci> to fill in the hostname field, the instance is working under control of the CCMS after a failover without any change.

If an instance is running on the standby node in normal operation (and is stopped when switching over), the control console shows this instance to be down (for example, you will get a red node on a graphical display) after the switchover.

Configure the frontend PCs to attach to <relocci>. Most of the time, this can be achieved by distributing a new saplogon.ini file to the windows directory.

Installation is complete.

The next step is to do some comprehensive switchover testing covering all possible failure scenarios. It is important that all relevant SAP R/3 application functionalities are tested on the switchover nodes. There exist several documents provided by HP or SAP R/3 that can guide you through this process.