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

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.
Installation Step: IS1190
A SAP Internet Communication Manager (ICM) may run as part of any Application Server.
It is started as a separate multi-threaded process and can be restarted independently from the Application
Server. E.g. usage of BW web reporting, Business Server Pages (BSP) rely on ICM to work properly. In
scenarios using external web communication, one or more SAP Web Dispatcher often accompanies the
ICMs. The SAP Web Dispatcher can be layed out redundantly with hardware load balancing. SAP also
allows Serviceguard Extension for SAP on Linux packaging for a single Web Dispatcher.
To find out if ICM is configured as part of an Application Server, check for the following SAP profile parameter:
rdisp/start_icman=TRUE
ICM gets switched over with the Instance package. In order to make it work, ICM has to be registered with
the Message Server using a virtual IP address.
This mechanism is different from SAPLOCALHOST and SAPLOCALHOSTFULL since ICM allows HTTP Server
Aliasing via icm/server_port_<nn> settings. During startup, icman reads its configuration and propagates
it to the SAP Message Server or the SAP Web Dispatcher Server. These servers then act as the physical point
of access for HTTP requests. They classify requests and send HTTP redirects to the client in order to connect
them to the required ICM Instance.
This only works properly if the bound ICM instances propagate virtual IP addresses. Therefore a parameter
icm/host_name_full=<relocatible_ip>
needs to be set within the Instance Profile of the Application Server.
Double-check the settings with report RSBB_URL_PREFIX_GET or review the parameters within the SMMS
transaction.
Installation Step: IS1200
If you cluster ci, 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.
SAP J2EE Engine specific installation steps
This section is applicable for SAP J2EE Engine 6.40 based installations that were performed prior to the
introduction of SAPINST installations on virtual IPs. There is a special SAP OSS Note 757692 that explains
how to treat a hostname change and thus the SAP adoptive computing benefits of a SAP J2EE Engine 6.40.
Depending on the SAP application component that is clustered, there might be additional steps documented
as part of a SAP whitepaper that covers clustering of the component.
Installation Step: NW04J1210
If the SAP component installed also depends and utilizes a SAP J2EE Engine, some configuration tasks have
to be performed in order for the J2EE instance to interact in an environment with virtual IPs.
The following lines will give some hints about the settings necessary for the switchover of the J2EE Engine
6.40, but always refer to SAP OSS Note 757692 because this note is always kept up-to-date.
For virtualizing the J2EE DB Connection:
• Log on to the J2EE Configuration Tool
• Choose secure store
• Change the following values: -
admin/host/<SID> <relocdb>
For Oracle databases replace the hostname in the connection string:
jdbc/pool/<SID>/Url jdbc:oracle:thin@<relocdb>:1527:<SID>
Installation Step: NW04J1220
100 Step-by-Step Cluster Conversion