Sap Ha Pi

Disclaimer
IBMs statements regarding its plans, directions, and intent are subject to change or withdrawal
without notice at IBMs sole discretion.
Information regarding potential future products is intended to outline our general product
direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment, promise,
or legal obligation to deliver any material, code or functionality.
Information about potential future products may not be incorporated into any contract.
The development, release, and timing of any future features or functionality described for our
products remains at our sole discretion.
Please refer to the developerWorks terms of use for more information.
-i-
Table of Contents
Chapter 19. SAP High Availability Policy................................................................5
High availability concepts for a SAP system.....................................................5
Single Point of Failure (SPOF).............................................................................6
(A)SCS node................................................................................................6
Primary AS node...........................................................................................6
Additional Application Server node..............................................................7
Web Dispatcher and SAProuter node..........................................................7
Host Agents..................................................................................................7
Database node.............................................................................................7
NFS node.....................................................................................................7
SAP clients...................................................................................................7
Example of a two-node setup...............................................................................7
SAP HA setup options...........................................................................................8
ASCS HA setup..............................................................................................10
ASCS HA setup..........................................................................................10
Primary and Additional AS node.................................................................10
Web Dispatcher and SAProuter node (optional)........................................11
Database HA setup.....................................................................................11
NFS HA setup.............................................................................................11
Java SCS HA setup........................................................................................12
Java SCS HA setup....................................................................................12
Primary and Additional AS node.................................................................12
Web Dispatcher and SAProuter node (optional)........................................13
Database HA setup....................................................................................13
NFS HA setup.............................................................................................13
Location of SAP instance directories..................................................................14
Database HA installation setup...........................................................................14
SAP Central Services and database in the same HA cluster.........................14
SAP Central Services and database on different HA clusters........................14
High availability for DB2 and other databases...............................................15
DB2 HA Setup............................................................................................15
High availability with other databases........................................................15
NFS HA installation setup...................................................................................15
High availability impact.......................................................................................16
Interactions between Enqueue Server and Enqueue Replication Server......18
Database host.................................................................................................20
NFS server......................................................................................................20
SAP Host Agent..............................................................................................20
SAP Web Dispatcher......................................................................................21
SAProuter.......................................................................................................21
Planning the SAP HA solution........................................................................... 21
Installing a new high-availability SAP system............................................21
Exporting an existing non-HA SAP system................................................21
Post-installation tasks.................................................................................21
Installing a new ASCS or SCS HA SAP system.................................................21
-1-
Prerequisites...................................................................................................22
Prerequisite installation tasks.....................................................................22
Initial installation on primary node..................................................................23
Initial installation on failover node..................................................................23
Required adaptions of SAP profiles................................................................24
Verifying the initial installation.........................................................................24
Installing and setting up System Automation for Multiplatforms...................27
Prerequisites.......................................................................................................27
Installing System Automation for Multiplatforms on all cluster nodes................27
Granting System Automation for Multiplatforms access for the <sapsid>adm...28
Setting up the domain.........................................................................................28
Setting up a tie breaker.......................................................................................29
Enabling syslog daemon.....................................................................................29
Installing the SAP HA policy feature...................................................................29
Packaging.......................................................................................................29
Installing the SAP HA policy feature license...................................................30
Restrictions.....................................................................................................30
Enabling the SAP HA Connector........................................................................30
Configuring and activating the SAP HA solution.............................................31
The SAP HA policy..............................................................................................31
ASCS HA policy..............................................................................................32
The ABAP SAP Central Services group (ASCS).......................................35
The ABAP Enqueue Replication Server group..........................................35
Interactions between Enqueue Server (ES) and Enqueue Replication
Server (ERS)..............................................................................................36
Java SCS HA policy........................................................................................39
The Java SAP Central Services group.......................................................42
The Java Enqueue Replication Server group............................................43
Parts of the ABAP and Java policies with the same behavior........................43
The ABAP and Java Application Server (AS) groups.................................43
The ABAP and Java SAProuter group.......................................................43
The ABAP and Java SAP Web Dispatcher group......................................44
The Host Agent groups...............................................................................44
Policy parameters...............................................................................................44
SAP ABAP Central Services (ASCS) -Enqueue Replication Server (ERS) HA
policy (ABAP)..................................................................................................44
SAP JAVA Central Services (SCS) -Enqueue Replication Server (ERS) HA
policy (Java)....................................................................................................54
Migration steps....................................................................................................64
Overview.........................................................................................................64
Migration considerations.....................................................................................64
Migrating the SAP HA policy.............................................................................64
Upgrade your SAP cluster to System Automation for Multiplatforms 3.next..65
Granting System Automation for Multiplatforms access for the <sapsid>adm
........................................................................................................................65
Create a new SAP HA automation policy.......................................................65
-2-
Change SAP profile parameters.....................................................................65

Enable the SAP HA connector........................................................................66
Activate and verify the new System Automation for Multiplatforms 3.next SAP
HA policy.........................................................................................................66
Using the wizard to configure and activate the SAP HA solution...................66
Verifying the SAP HA solution...........................................................................67
Starting and stopping SAP HA............................................................................67
Failover scenarios...............................................................................................68
Test setup.......................................................................................................68
Scenarios........................................................................................................68
Checklist for SAP HA solution........................................................................... 71
-3-
Figures
Figure 1: Components of a distributed SAP system.....................................................6
Figure 2: Example of a two-node setup........................................................................8
Figure 3: ASCS HA setup............................................................................................10
Figure 4: Java SCS HA setup......................................................................................12
Figure 5: Initial startup of (A)SCS................................................................................19
Figure 6: Failure of (A)SCS and recovery of the enqueue table.................................19
Figure 7: Movement of the Enqueue Replication Server............................................20
Figure 8: ASCS HA policy............................................................................................32
Figure 9: Relationships between the Enqueue and Message Servers and the
Enqueue Replication Server........................................................................................36
Figure 10: Java SCS HA policy...................................................................................39
Index of Tables
Table 1: ABAP resources and the corresponding components...................................11
Table 2: Java resources and the corresponding components....................................13
Table 3: Fully implemented high availability solution for SAP.....................................17
Table 4: Resources and resource groups of the ASCS HA policy..............................33
Table 5: Description and examples of placeholders for ABAP resource names.........35
Table 6: Resources and resource groups of the Java SCS HA policy........................40
Table 7: Description and examples of placeholders for JAVA resource names..........42
Table 8: ABAP policy parameters................................................................................44
Table 9: Java policy parameters..................................................................................54
Table 10: Location for the SAP HA XML template files...............................................66
Table 11: Planned Outages.........................................................................................68
Table 12: Unplanned outages......................................................................................70
Table 13: SAP HA solution checklist............................................................................71
-4-
Chapter 19. SAP High Availability Policy

High availability concepts for a SAP system
This chapter explains the high availability concepts for a SAP system. It provides
information about which SAP HA policy to choose depending on the planned SAP
installation. The main reason for this high availability setup is to reduce the
downtime of an SAP system in case of software or hardware failures.
The following topics are covered in this chapter:
Single Point of Failure (SPOF) on page 6
Example of a two-node setup on page 7
SAP HA setup options on page 8
Database HA installation setup on page 14
NFS HA installation setup on page 15
High availability impact on page 16
The high availability solution for SAP uses System Automation for Multiplatforms to
automate all SAP components. System Automation for Multiplatforms detects failed
components, restarts them or initiates a failover. This setup will also help to reduce
the operational complexity of an SAP environment and to avoid operator errors
resulting from this complexity.
-5-
Single Point of Failure (SPOF)

In a distributed or standard SAP installation the SAP Central Services or SAP Central
Instance, the database server, and the NFS server are single points of failures
(SPOFs). To minimize the impact of SPOF services outages, it is necessary to setup
redundancy. This requires to run one or more standby servers to which each of the
SPOF services can be failed over and restarted independently. Each SPOF service
must be associated with its own virtual hostname which is started where the service
runs. This allows the clients to reconnect to the same hostname independently of
where the SPOF service runs.
The following SAP components are available for a distributed SAP system.
Host Agents
Host
HostAgent
Agent
Host
HostAgent
Agent
Host
HostAgent
Agent
Figure 1: Components of a distributed SAP system
(A)SCS node
The (A)SCS node consists of the standalone components Enqueue Server
(ES) and Message Server (MS) that operate as SAP Central Services instance.
Depending on the SAP solution the SCS Node contains the ABAP or Java
components.
In addition there is an SAP Instance Agent running for each instance.
SAP uses the following terms and abbreviations:
ASCS
SAP Central Services for ABAP instances.
SCS
SAP Central Services for Java instances.
(A)SCS
SAP Central Services for ABAP or Java instances.
Primary AS node
The Primary AS node consists of the Primary Application Server (PAS)
-6-
instance running the SAP Services Dialog, Update, Batch, Gateway and
Spool. An Instance Agent accompanies the Primary Application Server.
Note:
In a standard non-distributed SAP system all the main instances

(SCS, PAS and database) run on the same node.
Additional Application Server node

Additional AS nodes are optional. They host the Additional Application
Server (AAS) instances which were called Dialog Instance (DI) in releases
prior than SAP kernel 7.1. You can have one or more Additional Application
Servers. Again an Instance Agent accompanies each Additional Application
Server.
Web Dispatcher and SAProuter node
The optional Web Dispatcher and SAProuter nodes run the SAP Web
Dispatcher (WD) and SAProuter which are used as proxies to access the
other SAP instances.
In addition there is an Instance Agent running for the Web Dispatcher.
Host Agents
One SAP Host Agent runs on each node that hosts SAP provided
components.
Database node
The database node holds the database instance. The database product can be
IBM DB2 or another SAP supported database.
NFS node
The NFS node runs the NFS server. It can also be a NAS device which
exports the NFS file systems.
SAP clients
The SAP clients connect directly to the Application Servers or to an optional
Web Dispatcher.
For more information about the SAP components, refer to High availability impact
on page 16.
Example of a two-node setup

The minimum hardware setup consists of a two-node System Automation for
Multiplatforms domain. The two nodes are either two physical machines or two
LPARs running on different physical machines. The systems must be connected via
network and need to access the database and SAP data. Data can be provided by a
SAN attached disk subsystem, which is connected to each node using fiber channel
(FC).
Figure 2 on page 8 shows an example of a two-node System Automation for
Multiplatforms domain. It shows all the main SAP instances and the corresponding
failover groups of a SAP ABAP system.
-7-
Figure 2: Example of a two-node setup
Each machine or LPAR must be capable to run all instances. These are the main SAP
instances, which must be made highly available by System Automation for
Multiplatforms. High availability for application servers is achieved by having at
least two application server instances (PAS and AAS) as fixed resources.
If the setup contains the database server, SAProuter or SAP Web Dispatcher, they
should be made highly available as well.
SAP HA setup options

System Automation for Multiplatforms supports two different SAP HA installation
setups:
ASCS HA installation
Java SCS HA installation

-8-
Select the HA installation which matches your SAP installation.

Note: To transform your existing SAP into a highly available SAP, keep your
existing SAP up and running until the newly installed SAP HA setup is
tested.
-9-
ASCS HA setup
This ASCS HA setup is used for ABAP only SAP solutions.
Figure 3: ASCS HA setup
ASCS HA setup
The ASCS HA setup consists of at least two SCS nodes which run the ASCS
and ERS instances. Under regular conditions the ERS will always be started
on the node where the ASCS is not running. This failover setup has no
downtime due to fast failure detection and in-memory data exchange between
ES and ERS in case the ASCS must be moved to the failover node. During
the failover, the virtual IP address for the ASCS is moved to the failover node
too, so its addressing remains unchanged.
Primary and Additional AS node
The Primary AS node and the Additional AS nodes consist of ABAP
Application Servers which will be restarted in place in case of software
failures. Protection against hardware outages is done by setting up multiple
Application Servers on different hardware. Therefore the System Automation
for Multiplatforms concept for SAP HA does not consider failovers of
Application Servers to other nodes because Application Server restarts take a
lot of time. Other Application Servers must be sized to take the additional
workload from failing servers.
- 10 -
Web Dispatcher and SAProuter node (optional)

The Web Dispatcher and SAP router HA setups consists of at least two nodes
which run the instances in a failover setup. The components are key for the
clients to access the Application Servers, so in case of a failure the instance
failover to standby nodes includes their virtual IP addresses too.
Database HA setup
The database HA setup is explained in Database HA installation setup on
page 14.
NFS HA setup
The NFS HA setup is explained in NFS HA installation setup on page 15.
Table 1 on page 11 lists the required component setup for a SAP HA solution.
Table 1: ABAP resources and the corresponding components
ABAP Resources
ABAP resources
ABAP independent resources

(optional)
SAP component
ABAP SAP Central Services (ASCS) instances
using an own virtual hostname on two nodes.
Enqueue Replication Server using an own
virtual hostname on two nodes.
Database Server instances using an own virtual
hostname on two nodes.
Primary Application Server for ABAP instance
on first node.
Additional Application Server for ABAP
instances on other nodes.
Host Agent
Web Dispatcher instances using an own virtual
SAProuter setup on two nodes.
- 11 -
Java SCS HA setup

This Java SCS HA setup is used for Java only SAP solutions.
Figure 4: Java SCS HA setup
Java SCS HA setup

The Java SCS HA setup consists of at least two SCS nodes which run the
SCS and ERS instances. Under regular conditions the ERS will always be
started on the node where the SCS is not running. This failover setup has no
downtime due to fast failure detection and in-memory data exchange between
ES and ERS in case the SCS must be moved to the failover node. During the
failover, the virtual IP address for the SCS is moved to the failover node too,
so its addressing remains unchanged .
Primary and Additional AS node
The Primary AS node and the Additional AS nodes consist of Java
Application Servers which will be restarted in place in case of software
failures. Protection against hardware failures is done by setting up multiple
Application Servers on different hardware. Therefore the System Automation
for Multiplatforms concept for SAP HA does not consider failovers of
Application Servers to other nodes because Application Server restarts take a
lot of time. Other Application Servers must be sized to take the additional
workload from failing servers.
- 12 -
Web Dispatcher and SAProuter node (optional)

The Web Dispatcher and SAP router HA setups consists of at least two nodes
which run the instances in a failover setup. The components are key for the
clients to access the Application Servers, so in case of a failure the instance
failover to standby nodes includes their virtual IP addresses too.
Database HA setup
The database HA setup is explained in Database HA installation setup on
page 14.
NFS HA setup
The NFS HA setup is explained in NFS HA installation setup on page 15.
Table 2 on page 13 lists the required component setup for a SAP HA solution.
Table 2: Java resources and the corresponding components
Java Resources
Java resources
Java independent
resources (optional)
SAP component
Java SAP Central Services (SCS) instances using an
own virtual hostname on two nodes.
Enqueue Replication Server using an own virtual
Database server instances using an own virtual
Primary Application Server for Java instance on first
node.
Additional Application Server for Java instances on
other nodes.
Host Agent
Web Dispatcher instances using an own virtual
SAProuter setup on two nodes.
- 13 -
Location of SAP instance directories

The SAP instance directories /usr/sap/<sapsid>/<instancename> must be
located on a local filesystem. NFS or other distributed filesystems are not allowed or
accepted.
Database HA installation setup

You can choose between a database installation within the same System Automation
for Multiplatforms cluster together with the SAP installation or a database
installation on a separate cluster of its own.
SAP Central Services and database in the same HA cluster
If you choose to install the database on the same System Automation for
Multiplatforms cluster as SAP, you can run them on the same or on different systems.
(A)SCS and database running on the same nodes (2 or 3 nodes): Use this setup
only if your workload is small enough, so that the database and the SAP Enqueue
Server can run on one system and the SAP Primary Application Server on the other
system.
(A)SCS and database running on different nodes in same cluster (4 or more
nodes): Use this setup to separate the workload of the SAP installation and the
database server to different systems. Additional nodes can be joined into this cluster
to host Additional Application Servers within this HA setup.
When using the policy wizard to define your SAP HA policy, it is recommended to
select a "StartAfter" relationship between the SAP Application Servers and the
database server. This relationship will let the database server start before the SAP
Application Servers are started. This helps to avoid the problem of having an
Application Server started without a database running, which would require a restart
of the Application Server.
SAP Central Services and database on different HA clusters
If you have the SAP installation and the database in different System Automation for
Multiplatforms HA clusters you have the following advantages:
1. The setup and maintainance of the database HA cluster is independent from
the SAP HA cluster.
2. Separate non-root user authorizations for cluster commands against DB2 and
SAP resources can be better applied when using separate System Automation
for Multiplatforms clusters.
Note: In case you have a DB2 database you can use the SAP installer to install DB2
and System Automation for Multiplatforms together on the database nodes.
For more information, refer to DB2 HA Setup on page 15.
As a drawback, although there are functional dependencies between SAP and its
database, they cannot be mapped to HA relationships across two clusters with System
Automation for Multiplatforms. Such cross-cluster relationsships can be
implemented with the Tivoli System Automation Application Manager product.
- 14 -
High availability for DB2 and other databases

You can either use DB2 for your HA setup or use other databases.
DB2 HA Setup
In a high availability environment a DB2 HA setup is required. You can use the
System Automation for Multiplatforms software which is bundled with DB2.
Note: If the DB2 database runs in the same cluster together with the SAP software,
the DB2-bundled System Automation for Multiplatforms license cannot be
used, because it allows the automation of DB2 only. So you must ensure that
you have a full System Automation for Multiplatform license for each cluster
node.
Use the DB2 HA setup wizard which is shipped with the SAP product.
You can find the DB2 HA setup installation information in the following chapters of
the SAP Installation & Upgrade Guides. A SAP user ID and password are required to
access the SAP documentation:
SAP NetWeaver 7.0 (2004s) Installation (2 -Installation -SAP NetWeaver

Systems)
SAP NetWeaver PI 7.1 Installation (2 -Installation -SAP NetWeaver Systems)

- IBM Tivoli System Automation for MultiPlatforms-DB2 for LUW
SAP NetWeaver 7.3 Installation (2 -Installation -SAP NetWeaver Systems)

SAP NetWeaver 7.4 Installation (2 -Installation -SAP NetWeaver Systems)

Further links:
How to setup and run a DB2 LUW database server or client see SAP Note
No. 960843: DB6: Installation SA MP
For more information about high availability with SAP on DB2, refer to
IBM DB2 for LUW Cluster Using IBM Tivoli SA MP SAP Community
Network link: http://scn.sap.com/docs/DOC-14508.
High availability with other databases

System Automation for Multiplatforms can be used to automate the start, stop,
monitor, restart and failover of database servers other than DB2. You can find HA
policies for other databases on the following "IBM Service Management Library"
Web site: http://www.ibm.com/software/brandcatalog/ismlibrary/
search#rc=TivoliSystemAutomation:System%20Automation
NFS HA installation setup

There are two NFS shares which are essential for an SAP system:
/sapmnt/<SID>: Required to share binaries and configuration data for the

application servers.
/usr/sap/trans: Has to be shared in a logical transport landscape so that

the source SAP system can write the transport files to the share and the target
- 15 -
systems can pick them up from this location.

You have the following three options for an NFS HA setup:
1. Use System Automation for Multiplatforms for the NFS HA cluster.
2. Use an existing NFS HA cluster.
3. Use a Network Attached Storage (NAS) device with integrated HA
capabilities.
It is not supported to run the NFS server on the same cluster nodes as the SAP HA
solution, because then various SAP resources cannot be stopped due to open file
handles. If the NFS server shall run in the same cluster as the SAP HA solution, it
may only be started on nodes that do not host any of the SAP components.
The start of SAP by Systems Automation for Multiplatforms will not be successful if
the NFS server is not up and running. In case the NFS runs in a separate HA cluster,
it is not possible to define a "StartAfter" relationship across two clusters with System
Automation for Multiplatforms. Such a cross-cluster relationsships can be
implemented with the Tivoli System Automation Application Manager product.
Make sure to configure all nodes in the SAP HA solution cluster as NFS clients. Use
the automounter to configure the NFS clients. The SAP HA policy does not keep the
NFS mountpoints high available, therefore it is required to use the automounter for
keeping the NFS mountpoints high available.
An NFS HA policy is part of the SAP HA solution provided by System Automation
for Multiplatforms. See chapter chapter 20 (???) NFS High Availability Policy on
page nnn for details.
High availability impact

This section discusses the impact of various failure scenarios of the SAP system
components when using System Automation for Multiplatforms to automate
recovery. Manual recovery actions are minimized which otherwise would cause SAP
transactions to timeout and roll back.
Note: There is no single point of failure anymore if System Automation for
Multiplatforms is used for automation. The impact of a failure has a local
scope; it is limited to the transactions currently using the failing resource. The
SAP system remains available.
Without System Automation the impact on the SAP system would be much
worse from what is shown in the "Impact" column in the table below. Without
System Automation all recovery actions would have to be done manually.
Manual recovery actions usually take longer and are error prone under the
pressure of a system outage.
In Table 3 on page 16 the following abbreviations are used:
SA: actions taken automatically and instantaneously by System Automation

for Multiplatforms
User: actions taken by the user
Table 3: Fully implemented high availability solution for SAP
- 16 -
Failing resource
Database
Impact
Rollback of transactions
Remote application servers
fail over automatically to
the other database node
Enqueue Server
No impact.
Enqueue
Replication
Server
Message Server
Application
Server instance
SAP-Gateway
Web Dispatcher
SAProuter
Actions
SA: Restart or Failover
Database (Optional setup in
same HA cluster)
User: Restart transactions
SA: Failover Enqueue Server
Remote application servers
automatically reconnect to
the other database node.
Refer to Interactions between

Enqueue Server and Enqueue
Replication Server on page 18.
No impact.
SA: Restart Enqueue
Replication Server
Refer to Interactions between
Enqueue Server and Enqueue
Replication Server on page 18.
No impact on most
SA: Restart Message Server
transactions
SA: failover optional
Certain transactions
inhibited (for example,
SAP restart feature enabled.
SM66)
Update/batch workload
balancing inhibited
Group logon inhibited
Transactions on this
User: Connect to another
Application Server instance
instance are lost
Rollback of database
User: Restart transactions
updates
User sessions on this
SA: Restart Application
instance are lost
Server instance
No impact on most
SA: Restart SAP-Gateway
transactions
Connections to registered
servers inhibited until they
have reconnected to the
SAP-Gateway
User sessions (via HTTP)
SA: Restart or Failover Web
Dispatcher
lost
User: Reconnect
Re-connection inhibited
User sessions (via

SAProuter) lost
Re-connection inhibited
- 17 -
SA: Restart or Failover

SAProuter
User: Reconnect
Failing resource Impact

NFS server, NAS Refer to NFS server on
device
page 20.
If data was written to file,
last written data is in doubt
Actions
SA: Restart or Failover NFS
server
(Note: The HA setup of SAP
and NFS on the same cluster
nodes is not supported).
Interactions between Enqueue Server and Enqueue Replication Server

The availability of the Enqueue Server is key for a SAP system. If the Enqueue
Server cannot be reached, the SAP system is not operational since most transactions
fail to run.
The Enqueue Server is a stand-alone component and does not require access to the
database. An application server instance connects directly to the Enqueue Server by
using a virtual hostname.
When connected, the Enqueue Server on system 1 transmits replication data to the
Enqueue Replication Server on system 2 which stores the data in a shadow enqueue
table residing in shared memory. In case the Enqueue Server fails, the shadow
enqueue table on the Enqueue Replication Server is used to rebuild the tables and
data structures for the recovered Enqueue Server that is started on the same node.
The Enqueue Replication Server stops after transferring the data to the recovered
Enqueue Server.
If the Enqueue Replication Server is unavailable, the SAP system continues to be up
and running, but no shadow enqueue table is maintained as a backup. The Enqueue
Replication Server runs on a different system than the Enqueue Server to keep the
enqueue table and its shadow backup apart.
The multithreaded architecture of the stand-alone Enqueue Server allows parallel
processing and replication. The I/O processing for the TCP/IP communication is
distributed over several I/O threads which allows a very high throughput.
Figure 5 on page 19 shows the principal TCP/IP communication paths between the
Application Server instances, the Enqueue and Message Servers.
- 18 -
virtual
virtual
IPIP
address
address
virtual
IP
address
Figure 5: Initial startup of (A)SCS
If system 1 fails, system 2 takes over the role of the first one as shown in Figure 6 on
page 19:
1. The virtual IP address related to the Enqueue and Message Servers is taken
over to system 2.
2. Enqueue and Message Servers are restarted on system 2.
3. The enqueue table is rebuilt from the shadow table hosted by the Enqueue
Replication Server.
4. The Enqueue Replication Server stops after the Enqueue Server has rebuild
the enqueue table.
5. The Application Servers reconnect to the Enqueue and Message Servers.
System Automation for Multiplatforms will handle this complete failover process.
The failover is fully transparent to the application. Enqueue locks are preserved and
transactions continue to run.
virtual
virtual
IPIP
address
address
virtual
IP
address
Figure 6: Failure of (A)SCS and recovery of the enqueue table
- 19 -
After a successful failover of the Enqueue Server, the Enqueue Replication Server is
no longer needed on system 2 and therefore stops itself. If another system is
available, the Enqueue Replication Server is started by System Automation for
Multiplatforms on that system and a new shadow enqueue table is established. This is
shown in Figure 7 on page 20.
virtual
virtual
IPIP
address
address
virtual
IP
address
Figure 7: Movement of the Enqueue Replication Server
Database host
If the database server is not available, the entire SAP system becomes unavailable.
The database host maintains the persistent storage for the entire SAP system. Once
the database is available again, all uncommitted transactions are rolled back and the
SAP system continues to run.
monitor, restart and failover of the database server. For more information, refer to
High availability for DB2 and other databases on page 15.
NFS server
A SAP HA setup requires shared access for directories like global, profile, trans.
On UNIX and Linux systems you need NFS to share files. Thus the availability of
the file systems together with the NFS server is critical.
Note: NFS file access is not transactional. There is no commit or rollback logic. In
case of system failure or communication loss there is no guarantee that the
last written data has been stored on disk.
monitor, restart and failover of the NFS server. For more information, refer to NFS
HA installation setup on page 15.
SAP Host Agent
The SAP Host Agent is a tool that you can use for monitoring and controlling SAP
and non-SAP instances, operating systems, and databases. It is installed
automatically during the installation of new SAP instances with SAP kernel 7.20 or
- 20 -
higher.
The SAP Host Agent provides features for SAP instance discovery and inventory,
instance control, database monitoring and management, and operating system
monitoring using saposcol. It aids in system or instance provisioning by hosting the
infrastructure of SAP NetWeaver Landscape Virtualization Management (LVM).
SAP Web Dispatcher
The Web Dispatcher is the entry point for all external HTTP requests and the
interface between all HTTP clients and the SAP system. The Web Dispatcher can
work as load balancer for incoming requests which are distributed among all
available application servers.
When the SAP Web Dispatcher fails, clients cannot connect to the SAP subsystems
using HTTP request.
SAProuter
The SAProuter controls the access between the external network and the SAP
subsystem.
In case of a failure of the SAProuter, no connections can be processed using this
proxy.
Planning the SAP HA solution

This chapter describes the planning of your SAP HA solution.
The following three installation options apply if you want to setup a SAP high
availability solution:
Installing a new high-availability SAP system
Install a new system using the sapinst installation option "High-Availability
System". This option is described below in the chapter Installing a new
ASCS or SCS HA SAP system on page 21.
Exporting an existing non-HA SAP system
Export an existing non-HA SAP system and import it into a new highavailability SAP system using the system copy feature of sapinst. Refer to the
SAP documentation for assistance.
Post-installation tasks
Setup your NFS HA server. For more information, refer to NFS HA

installation setup on page 15. This task can also be done before you start the
SAP installation.
Setup your database HA server. For more information, refer to Database HA

installation setup on page 14.
Installing a new ASCS or SCS HA SAP system

This chapter describes a new installation of a ASCS or SCS HA SAP system. SAP
NetWeaver 7.0 or higher with a kernel version of at least 7.20 is required. This
description is based on a two node cluster architecture with a primary and a failover
node.
- 21 -
The installation is divided into three parts:

1. Initial installation on primary node on page 23.
2. Initial installation on failover node on page 23.
3. Required adaptions of SAP profiles on page 24.
4. Verifying the initial installation on page 24.
For more information about the ASCS or SCS HA SAP system setups, refer to SAP
HA setup options on page 8.
Prerequisites
Before you begin, make sure to follow the guidelines below:
1. Use unique instance numbers for every instance you install on a single host
for one SAPSID. The SAP installation will not work if you did not use unique
instance numbers.
2. The installation tasks for the primary and failover node contain ASCS and
SCS installation tasks. Depending on your application stack (ABAP only,
Java only) you may skip the ASCS or SCS installation tasks.
3. The SAP product documentation installation guide recommends to install the
switchover software after you have installed the Central Services Instance. If
you use System Automation for Multiplatforms, skip this step until you have
installed and verified the complete SAP system.
4. Check SAP note 1704753 Installing Systems based on NetWeaver 7.1 and
higher: UNIX
Prerequisite installation tasks
Note: The SAP installation tool sapinst is also called Software Provisioning
Manager in the SAP HA documentation.
Create an separate directory for every installation task to store installation

logs and traces. Switch into this directory before you start sapinst.
Ensure to set the correct ulimits and umask values for your environment as it
is documented in the SAP product installation guide.
Ensure to configure the automounter on all nodes to connect to the NFS

server and automatically mount the default SAP directory /sapmnt before
starting sapinst. For more information about NFS, refer to NFS HA
installation setup on page 15.
Register permanent entries for the virtual hostnames in the DNS server.
Ensure that the network interfaces that you want to use have the same name
on each system. For each virtual IP address defined in the HA policy, an
equivalency of network interfaces will be created. Only network interfaces
with the same name on each node can be part of each equivalency.
Temporarily define and activate all required virtual IP addresses on the

physical host where you want to start the installation before starting sapinst.
Be sure to remove the virtual IP addresses after the installation has been
- 22 -
completed. Incorrect behaviour of the SAP HA solution occurs if you leave

the virtual IP addresses permanently defined.
Initial installation on primary node
Use the sapinst command to execute the following tasks for the installation option
SAP Systems "High-Availability System". For some installation tasks its
required to start sapinst with a virtual hostname.
1. Activate all virtual IP addresses corresponding to the virtual hostnames
before starting the installations.
2. Central Services Instance for ABAP (ASCS) or Java (SCS):
sapinst SAPINST_USE_HOSTNAME=<virtual (A)SCS hostname>
3. Enqueue Replication Server instances (ERS) for ASCS or SCS

sapinst SAPINST_USE_HOSTNAME=<virtual ERS hostname>
4. Database instance
sapinst SAPINST_USE_HOSTNAME=<virtual DB hostname>
5. Primary Application Server instance

sapinst
6. Web Dispatcher instance (optional)

sapinst SAPINST_USE_HOSTNAME=<virtual Web Dispatcher hostname>
7. Remove all virtual IP addresses that have been activated before.

Initial installation on failover node
To install SAP on the failover node, perform the following steps:
1. Activate all virtual IP addresses corresponding to the virtual hostnames
before starting the installations:
2. Use the sapinst command to execute the following tasks with the installation
option System Copy Target System - High-Availability System".
Central Services Instance for ABAP (ASCS) or Java (SCS):

sapinst SAPINST_USE_HOSTNAME=<virtual (A)SCS hostname>
Enqueue Replication Server instances (ERS) for ASCS or SCS

sapinst SAPINST_USE_HOSTNAME=<virtual ERS hostname>
Database instance
sapinst SAPINST_USE_HOSTNAME=<virtual DB hostname>
3. Use the sapinst command to execute the following installation tasks using the
installation option SAP-System "High-Availability System":
Additional Application Server instance (old name: Dialog Instance)

sapinst
Web Dispatcher instance (optional):

Remove the existing Web Dispatcher SAPSID directory on /sapmnt
and install with the same SAPSID and instance ID on the second
node again.
sapinst SAPINST_USE_HOSTNAME=<virtual Web Dispatcher hostname>
4. Remove all virtual IP addresses that have been activated before.
- 23 -
Required adaptions of SAP profiles

Some changes have to be made to SAP profiles to comply with the HA solution
provided by System Automation for Multiplatforms
It is required to disable the SAP restart capability for the Enqueue Server and
the Enqueue Replication Server in the appropriate profiles. Otherwise the
automatic restart of SAP (executed by startsapsrv) mismatches with
System Automation for Multiplatforms start functionality and will cause
problems with the automation. Set the SAP profile parameter for EN and ERS
to Start_Program_<NR> in the EN and ERS profiles in the
/sapmnt/<SID>/profile directory.
For all servers other than EN and ERS set the SAP profile parameters
Restart_Program_<NR>.
Disable autostart of all SAP instances in all their profiles by commenting the
line Autostart = 1.
In order to share the enqueue backup file within the Linux or AIX cluster, it
should be stored on the NFS mounted /sapmnt/<SID>/global directory.
This way it can be accessed from all nodes in the cluster where the Enqueue
Server can start.
Add the following parameter to the (A)SCS profile for sharing the enqueue
backup files between nodes:
enque/backup_file = $(DIR_GLOBAL)/ENQBCK(A)SCS
All SAP ABAP services that run on the Primary Application Server
installation must also be manually configured in the instance profiles of the
Additional Application Server. The SAP ABAP services are:
Batch service
Update/Update 2 service
Spool service
Through this setup all SAP ABAP services are running on each Application
Server and are no single points of failure (SPOF) any more.
The SAP HA connector must be enabled in the default profile. This step
requires that System Automation for Multiplatforms is already installed on
the cluster nodes, so it probably must be done at a later time. Refer to
Enabling the SAP HA Connector on page 30 on how to enable the SAP HA
connector for your platform.
Verifying the initial installation

The following steps verify that a manual failover of the (A)SCS and ERS is possible.
This does not include the manual failover verification of the database.
The commands listed with each verification step assume an ASCS setup. If you
verify a Java setup replace the following instance names:
ASCS with SCS

DVEBMGS with J
D with J
- 24 -
The syntax of the ifconfig commands shown below applies to the AIX operating
system.
Prerequisites:
All instances are stopped.
Execute all steps as <sid>adm user.
Initial start: ASCS on first node and ERS on second node

1.
Start the ERS instance on the second node:

ifconfig <interface_name> <ERS_IP_alias> netmask <IP_netmask> alias up
startsap r3 ERS<ID>
2.
Start ASCS and the Primary Application Server instance on the first node:
ifconfig <interface_name> <ASCS_IP_alias> netmask <IP_netmask> alias up
startsap r3 ASCS<ID>
startsap r3 DVEBMGS<ID>
3.
Start the Additional Application Server instance on the second node:

startsap r3 D<ID>
Replication direction: ASCS on second node and ERS on first node

1.
Stop ERS and the Additional Application Server instance on the second node:
stopsap r3 ERS<ID>
stopsap r3 D<ID>
ifconfig <interface_name> <ERS_IP_alias> delete
2.
Stop ASCS and the Primary Application Servers instances on the first node:
stopsap r3 DVEBMGS<ID>
stopsap r3 ASCS<ID>
ifconfig <interface_name> <ASCS_IP_alias> delete
3.
Start ASCS instances on the second node:

4.
Start ERS instances on the first node:

startsap r3 ERS<ID>
5.
Check replication status for ERS instance on the first node using ensmon
utility:
ensmon pf=/usr/sap/<SID>/ERS<ID>/profile/<SID>_ERS<ID>_<node1>
Select task Get replication information. The output looks like this
...Replication is enabled in server, replication server is connected.
Replication is active...
6.
Start the Primary Application Server instance on the first node:

7.
Start the Additional Application Server instance on the second node:

startsap r3 D<ID>
8.
Verify successful start of all Application Servers:

- 25 -
Logon to the Primary Application Server for ABAP using the SAP graphical
user interface (SAPGUI).
Logon to the Additional Application Server for ABAP using the SAP
graphical user interface (SAPGUI).
Logon to the Primary Application Server for Java using a Web browser. The
default is:
http://node1:5<ID>00/index.html
Logon to the Additional Application Server for Java using a Web browser.
The default is:
Replication direction: ASCS on first node and ERS on second node:

1.
Stop ERS and Primary Application Server instance on the first node:
stopsap r3 DVEBMGS<ID>
stopsap r3 ERS<ID>
ifconfig <interface_name> <ERS_IP_alias> delete
2.
Stop ASCS and Additional Application Servers instances on the second node:
stopsap r3 D<ID>
stopsap r3 ASCS<ID>
ifconfig <interface_name> <ASCS_IP_alias> delete
3.
Start ASCS instances on the first node:

4.
Start ERS instances on the second node:

startsap r3 ERS<ID>
5.
Check replication status for ERS instance on the second node using ensmon
utility:
ensmon pf=/usr/sap/<SID>/ERS<ID>/profile/<SID>_ERS<ID>_<node2>
Select task Get replication information. The output looks like this
...Replication is enabled in server, replication server is connected.
Replication is active...
6.
Start Primary Application Server instance on the first node:

7.
Start Additional Application Server instance on the second node:

startsap r3 D<ID>
8.
Verify successful start of all Application Servers:
Logon to the Primary Application Server for ABAP using the SAP graphical
user interface (SAPGUI).
Logon to the Additional Application Server for ABAP using the SAP
graphical user interface (SAPGUI).
Logon to the Primary Application Server for Java using a Web browser. The
default is:
- 26 -
Logon to the Additional Application Server for Java using a Web browser.
The default is:
Installing and setting up System Automation for Multiplatforms

This chapter describes the installation and setup of System Automation for
Multiplatforms for an automated and highly available SAP system.
Check if you have the right prerequisites for System Automation for
Multiplatforms in a cluster environment : Prerequisites on page 27
Install System Automation for Multiplatforms on each node in your cluster:

Installing System Automation for Multiplatforms on all cluster nodes on
page 27
Grant access on each node for the sap user ID: Granting System Automation
for Multiplatforms access for the <sapsid>adm on page 28
Set up your domain: Setting up the domain on page 28
Set up the tie breaker: Setting up a tie breaker on page 29
Enable the syslog daemon: Enabling syslog daemon on page 29
Activate the feature license: Installing the SAP HA policy feature on page
29
Enabe the SAP HA Connector: Enabling the SAP HA Connector on page
Prerequisites
Refer to the following chapter for UNIX and Linux: Prerequisites on page nnn
Installing System Automation for Multiplatforms on all cluster

nodes
System Automation for Multiplatforms must be installed on all nodes. Proceed as
follows for each node:
1. Verify that your system has the necessary prerequisites for System
Automation for Multiplatforms. Enter the following command:
./prereqSAM
This command writes a log to /tmp/prereqSAM.<number>.log. Check this log

file before you proceed with the installation.
2. Install the System Automation for Multiplatforms software. Enter:
./installSAM
The command writes a log to /tmp/installSAM.<number>.log. Check this log

file to verify the installation.
- 27 -
3. Set and export the environment variable CT_MANAGEMENT_SCOPE to 2

for all users of System Automation for Multiplatforms. Verify your changed
settings. After you logged in, enter:
env | grep CT_MANAGEMENT_SCOPE
The output should be

CT_MANAGEMENT_SCOPE=2
For more information about the installation refer to Installing IBM Tivoli System
Automation on UNIX and Linux on page nnn.
Granting System Automation for Multiplatforms access for the

<sapsid>adm
The userid <sapsid>adm must have the authority to perform System Automation for
Multiplatforms commands which are launched by the SAP HA interface.
Refer to chapter Setting up security for System Automation for Multiplatforms
clusters in the IBM Tivoli System Automation for Multiplatforms Administrator's
and User's Guide to setup the non-root security for the <sapsid>adm userid. It is
sufficient to use the role sa_operator.
Setting up the domain

To set up the System Automation for Multiplatforms domain perform the following
steps:
1. Execute the following command on each node:
preprpnode <node1> <node2>
2. Create the SAP domain for System Automation for Multiplatforms, where
sap is the domain name (you might use another name of your choice):
mkrpdomain sap <node1> <node2>
3. Start the domain:

startrpdomain sap
4. Query the domain until it is displayed as online:

lsrpdomain
You should see output similar to

Name OpState RSCTActiveVersion MixedVersions TSPort GSPort
sap Online 3.1.5.2
No
12347 12348
5. Ensure that all nodes in the domain are online too:

lsrpnode
- 28 -
You should see output similar to:

Name
node1
node2
OpState
Online
Online
RSCTVersion
3.1.5.3
3.1.5.3
For more information on setting up a domain, refer to IBM Tivoli System Automation
for Multiplatforms Administrator's and User's Guide.
Setting up a tie breaker

If the number of nodes in the System Automation domain is even, a tie breaker needs
to be defined to solve situations, where the nodes cannot communicate with each
other.
For more information about on setting up a tie breaker, refer to IBM Tivoli System
Automation for Multiplatforms Administrator's and User's Guide.
Enabling syslog daemon

AIX only:
Activate syslog daemon to write into /tmp/syslog.out files. The syslog will
contain messages written by the System Automation for Multiplatforms scripts.
1. In /etc/syslog.conf activate/uncomment the entry:
*.debug /tmp/syslog.out rotate size 100k files 4
2. Create the log file (in case it does not exist):

touch /tmp/syslog.out
3. Refresh the syslog daemon.

refresh -s syslogd
Installing the SAP HA policy feature

Packaging
The code of the SAP HA policy feature is shipped as part of the System Automation
for Multiplatforms product, but you need a separate license to enable the code.
You get the license by ordering the SAP HA policy feature. The name of the license
file is sam41SAP.lic, which is stored in the following locations of the SAP HA
policy feature deliverables:
Electronic deliverable: If you obtain the SAP HA policy feature license

through electronic distribution, the license file is named ??????.txt. Rename
or copy the electronic distribution file to samv3.nextSAP.lic.
CD: Install the SAP HA policy feature license from the CD "IBM Tivoli
System Automation for Multiplatforms 3.next High Availability for SAP".
The license file is located in the directory SAM3nextFeatSAP/license.
- 29 -
Installing the SAP HA policy feature license

Before you can install the SAP HA policy feature license, you must install the
System Automation for Multiplatforms base product as described in Installing
System Automation for Multiplatforms on all cluster nodes on page 27.
Use the samlicm command to install the SAP HA policy feature license on all nodes
in the cluster.
Execute the following command to install the license on all nodes:
samlicm -i <license file location>/sam41SAP.lic
To verify that the feature license has been successfully installed, issue the following
command:
samlicm -s
The name of the SAP HA policy feature should appear as value of the Product
Annotation field in the output of the command. For example:
...
Product Annotation: SA for MP - SAP HA policy
Creation date: Fri Dec 6 00:00:01 MET 2013
Expiration date: Thu Dec 31 00:00:01 MET 2037
...
For more information on the samlicm command, refer to IBM Tivoli System
Automation for Multiplatforms Reference Guide.
Restrictions
If you edit the start, stop, and monitor scripts used in the SAP HA policy feature, no
support is provided for the modified scripts. The scripts will still be used to automate
your SAP installation, but you will find the message "Modified script not supported"
in the Syslog for each modified script.
Enabling the SAP HA Connector

After System Automation for Multiplatforms has been installed on all cluster nodes,
the SAP HA Connecter must be configured in the SAP profiles. It is sufficient to put
the required entries into the default profile.
Depending on whether you have an AIX or Linux platform, add the following entries
to the default profile of your SAP system (replace <SAPSID> with the SAPSID of
your SAP System):
AIX
#----------------------------------------------------------------------# SAP HA connector
#---------------------------------------------------------------------service/halib = /usr/sap/<SAPSID>/SYS/exe/uc/rs6000_64/saphascriptco.o
service/halib_cluster_connector = /usr/sbin/rsct/sapolicies/sap/bin/sap_tsamp_cluster_connector
LINUX
Replace <your platform> with the appropriate directory name
#----------------------------------------------------------------------# SAP HA connector
#-----------------------------------------------------------------------
- 30 -
service/halib = /usr/sap/<SAPSID>/SYS/exe/uc/<your platform>/saphascriptco.so

service/halib_cluster_connector = /usr/sbin/rsct/sapolicies/sap/bin/sap_tsamp_cluster_connector
Please also refer to SAP Note 1693245 - "SAP HA Script Connector Library" for
details about the latest patch level for the SAP HA Script Connector Library.
Configuring and activating the SAP HA solution

This chapter describes how to configure the SAP HA policy using the provided
wizard. Once the policy has the correct parameter values, you can activate your SAP
HA solution.
Understand the SAP HA policy: The SAP HA policy
Provide the SAP HA policy parameters: Policy parameters on page 44
Use the wizard to provide the policy parameters: Using the wizard to
configure and activate the SAP HA solution on page 66
The SAP HA policy

The SAP HA policy defines all SAP components as resources and starts and stops
them in a well defined sequence to provide high availability for your SAP system.
For each setup described in High availability concepts for a SAP system on page 5
there is a separate policy. See Table 10 on page 66 for a list of the policy files
depending on the SAP HA setup.
- 31 -
ASCS HA policy
Figure 10 on page 39 gives an overview of all resources that can be part of a ABAP
SCS HA policy.
Figure 8: ASCS HA policy
The ASCS HA policy consists of equivalencies, resource groups, floating and fixed
resources, that are connected to each other with various relationships.
Table 4 on page 33 gives an overview of all resources.
See Table 5 on page 35 for a description of the tags used for the resource names as
well as examples.
- 32 -
Table 4: Resources and resource groups of the ASCS HA policy
Name
ABAP Network
Equivalency
Network Interface
Network Interface
ERS Network
Equivalency
Network Interface
Network Interface
SAPRouter
Network
Equivalency
Network Interface
Network Interface
Web Dispatcher
Network
Equivalency
Network Interface
Network Interface
ABAP SAP Central
Services top-level
group
ABAP SAP
Instance Agent
group
ASCS Service
IP
Instance Agent
ABAP SAP
Central Services
group
Enqueue Server
Message Server
Enqueue
Replication Server
top-level group
ERS Instance
Agent group
Enqueue
Replication
Server ServiceIP
Instance Agent
Resource name (according to policy naming conventions)
Resource
Type
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_NETIF
Equivalency
<INTERFACENAME>:<NODENAME_1>
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_NETIF
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER_NETIF
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_NETI
F
Fixed
Fixed
Equivalency
Fixed
Fixed
Equivalency
Fixed
Fixed
Equivalency
Fixed
Fixed
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>
Group
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_SRV
Group
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_ip
Floating
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_sapstartsrv
Floating
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_ASCS
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_en
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ASCS>_ms
Group
Floating
Floating
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>
Group
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_SRV
Group
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_ip
Floating
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_sapstartsrv
Floating
Enqueue
Replication Server <A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_ERS
group
- 33 -
Group
Name
Enqueue
Replication
Server
Primary
Application Server
top-level group
Primary
Application
Server Instance
Agent group
Instance Agent
Primary
Application
Server group
Primary
Application
Server
Additional
Application Server
top-level group
Additional
Application
Server Instance
Agent group
Instance Agent
Additional
Application
Server group
Additional
Application
Server
SAProuter group
SAProuter
SAProuter Service
IP
SAP WEB
Dispatcher toplevel group
SAP WEB
Dispatcher
Instance Agent
group
SAP Web
Dispatcher
Service IP
Instance Agent

<A_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_ers
Resource
Type
Floating
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME>_<NODENAME_PRIMAR
Y>
Group
Y>_SRV
Group
Y>_sapstartsrv
Fixed
Y>_AS
Group
Y>_as
Fixed
<A_PREFIX>_<SAPSID>_<INSTANCE_NAME>_<NODENAME_ADDITI
ONAL>
Group
ONAL>_SRV
Group
ONAL>_sapstartsrv
Fixed
ONAL>_AS
Group
ONAL>_as
Fixed
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER_saprouter
Group
Floating
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER_ip
Floating
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>
Group
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_SRV
Group
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_ip
Floating
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_saps
tartsrv
Floating
- 34 -
Name
SAP WEB
Dispatcher group
SAP WEB
Dispatcher
Host Agent Group
Host Agent
Resource
Type
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_WD
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_sapw
ebdisp
Group
Floating
SAP_HOST_AGENT_<NODENAME>
Group
SAP_HOST_AGENT_<NODENAME>_ha
Fixed
Table 5: Description and examples of placeholders for ABAP resource names
Tag
<A_PREFIX>
<ROUT_PREFIX>
<WD_PREFIX>
<SAPSID>
<SAPWEBDISP_SID>
<INTERFACENAME>
<NODENAME_PRIMARY>
<NODENAME_ADDITIONAL>
<NODENAME_1>
<NODENAME_2>
<INSTANCE_NAME>
<INSTANCE_NAME_ERS>
<INSTANCE_NAME_WD>
Description
Prefix for resources, has to be specified
in policy. Use a meaningful value to
easily identify resources later.
Example
SAP System SID
LOP
Name of a network interface

Hostname of the node on which the AS is
running
Hostnames of the node on which the
ASCS Central Services and the Enqueue
Replication Server are allowed to run
SAP Application Server Instance Name
SAP Enqueue Replication Server
Instance Name
SAP Web Dispatcher Instance Name
eth0
ABAP,
SAPROUTER
sapnode01
sapnode01
DVEBMGS01
ERS10
WD00
The ABAP SAP Central Services group (ASCS)

The ABAP SCS group contains four floating resources: a ServiceIP, the Instance
Agent resource and the ABAP Enqueue and Message Servers. All are tied together by
"StartAfter" (SA) and "StopAfter" (SO) relationships. When the ASCS group is
started, the IP resource is started first. Once the IP resource is online, the Instance
Agent resource is started next, followed by the Enqueue Server and the Message
Server. All resoures are contained in collocated groups, so they will always be started
on the same node. All resources are mandatory group members. No restart is
attempted by System Automation for Multiplatforms if one of the resources fails, but
a failover of the whole group is triggered instead.
The ABAP Enqueue Replication Server group
The Enqueue Replication Server group contains three mandatory floating resources:
a ServiceIP, the Instance Agent resource and the ABAP Enqueue Replication Server
(ERS) itself. All are tied together by "StartAfter" (SA) and "StopAfter" (SO)
relationships. When the ABAP Enqueue Replication Server group is started, the
- 35 -
ServiceIP is started first, followed by Instance Agent and the ABAP enqueue
replication server.
Interactions between Enqueue Server (ES) and Enqueue Replication Server
(ERS)
A set of six relationships between the Enqueue and Message Servers and the
Enqueue Replication Server provide the most important rules for the high availability
of the SAP Central Services. Figure 9 on page 36 shows an overview of these
relationships which will be referred by their numbers as shown in the picture.
Figure 9: Relationships between the Enqueue and Message Servers and the
Enqueue Replication Server
A set of example scenarios best explain the functions of these relationships. Please
refer to the IBM Tivoli System Automation for Multiplatforms Administrator's and
User's Guide for a detailed explanation of relationships and their properties.
Be aware that ES and MS will always start collocated on the same node because of
their common group constraint.
Initial Start (All nodes are available)
ERS will start first (because of [1] and [7]), followed by ES and MS in succession.
Since ES was not online before the initial start, ES/MS will start on another node
than ERS because of [2], relationship [3] and [5] are not applicable in this situation.
So the shadow enqueue table is maintained by ERS on another node than then the
one on which ES is running.
Initial Start (Only one node is available in a two-node cluster)
Because of [2] and [5] ES/MS and ERS cannot be started on the same node. The
competitive situation is resolved by the priorites that are assigned to the groups of
ES/MS and ERS. The group holding ES and MS has a higher priority than the ERS
group, thus it will be started on the sole node (the IfPossibe condition relaxes
relationship [1]). Thus the SAP Central Services can be made available under the
adverse conditions.
- 36 -
Failure of ES
When the Enqueue Server fails, it will bring down all members of its group too
because ES is a mandatory member of the group. System Automation for
Multiplatforms will recover ES on the node where ERS is running because of [3]. So
ES can rebuild its enqueue table from the shadow that was maintained by ERS.
Relationship [5] does not apply to this situation nor does relationship [2] since ES
was Online before. MS (and the other group members too) will follow ES to the node
where it has been restarted.
There is also an optional restart feature for the Enqueue Server in the SAP profile
which is able to recover a failed ES on the same node. This restart feature must be
disabled (as advised by Required adaptions of SAP profiles on page 24), otherwise
ES would not start on the node where ERS runs, hence the rebuild of the enqueue
table would not be possible.
Failure of MS
While in former SAP releases System Automation fro Multiplatforms could attempt a
restart in-place on the same node for a failed Message Server, this is now not
working anymore when done by System Automation. The relationship [6] forces the
restart of MS on the node where ERS runs, thereby pulling all other group members
(including ES) to move to the ERS node too.
The restart feature for the Message Server in the SAP profile should be enabled to
recover a failed MS on the same node (as advised by Required adaptions of SAP
profiles on page 24). The described recovery action by System Automation for
Multiplatforms will be executed in case the SAP restart feature was not able to restart
MS on its former node.
ERS stop/relocation after ES or MS failure recovery
As described in the previous paragraphs, a failed ES will be restarted on the node
where ERS is running. After ES has recovered its enqueue table from the shadow
table, ERS will terminate itself and be restarted by System Automation for
Multiplatforms in succession. The restart of ERS will be anticollocated on another
node because of [5], but [4] will only allow a node where the appropriate ES
constituent is not Failed Offline, so ES would be startable on that node. All other
relationships do not apply here.
There is also an optional restart feature for the Enqueue Replication Server in the
SAP profile which is able to recover a failed ERS on the same node. This restart
feature must be disabled (as advised by Required adaptions of SAP profiles on
page 24), otherwise ERS would not start another node away from EN.
ERS failure
Should ERS fail for any reason in an otherwise up and running SAP system, it will
be restarted anticollocated to the ES node because of [5], but [4] will only allow a
node where the appropriate ES constituent is not Failed Offline. All other
relationships do not apply here.
As already mentioned before there is also an optional restart feature for the Enqueue
Replication Server in the SAP profile which must be disabled (as advised by
Required adaptions of SAP profiles on page 24).
- 37 -
The node where ES is running fails

This is a similar scenario as described in Failure of ES above, followed by the
ERS stop/relocation after ES or MS failure recovery scenario. However, in a twonode cluster, ERS cannot be restarted on another node as enforced by [5] as long as
the failed ES node is not recovered.
The node where ERS is running fails
This situation is similar to ERS stop/relocation after ES or MS failure recovery
described above. The restart of ERS will be anticollocated on another node because
of [5], but in a two-node cluster there would be no other node left, so ERS cannot be
restarted on another node as long as the failed ERS node is not recovered.
- 38 -
Java SCS HA policy
Figure 10: Java SCS HA policy
The Java SCS HA policy consists of equivalencies, resource groups, floating and
fixed resources, that are connected to each other with various relationships. Table 6
on page 40 provides an overview of all resources.
See Table 7 on page 42 for a description of the tags used for the resource names as
well as examples.
- 39 -
Table 6: Resources and resource groups of the Java SCS HA policy
Name
Java Network
Equivalency
Network Interface
Network Interface
ERS Network
Equivalency
Network Interface
Network Interface
SAPRouter
Network
Equivalency
Network Interface
Network Interface
Web Dispatcher
Network
Equivalency
Network Interface
Network Interface
Java SAP Central
Services top-level
group
Java SAP Instance
Agent group
ASCS Service
IP
Instance Agent
Java SAP Central
Services group
Enqueue Server
Message Server
SAP Gateway
Enqueue
Replication Server
top-level group
ERS Instance
Agent group
Enqueue
Replication
Server ServiceIP
Instance Agent

<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_NETIF
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_NETIF
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER_NETIF
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_NET
IF
Resource
Type
Equivalency
Fixed
Fixed
Equivalency
Fixed
Fixed
Equivalency
Fixed
Fixed
Equivalency
Fixed
Fixed
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>
Group
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_SRV
Group
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_ip
Floating
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_sapstartsrv
Floating
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_SCS
Group
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_en
Floating
Floating
Floating
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_ms
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_SCS>_gw
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>
Group
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_SRV
Group
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_ip
Floating
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_sapstartsrv
Floating
Enqueue
Replication Server <J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_ERS
group
- 40 -
Group
Name
Enqueue
Replication
Server
Primary
Application Server
top-level group
Primary
Application
Server Instance
Agent group
Instance Agent
Primary
Application
Server group
Primary
Application
Server
Additional
Application Server
top-level group
Additional
Application
Server Instance
Agent group
Instance Agent
Additional
Application
Server group
Additional
Application
Server
SAProuter group
SAProuter
SAProuter Service
IP
SAP WEB
Dispatcher toplevel group
SAP WEB
Dispatcher
Instance Agent
group
SAP Web
Dispatcher
Service IP
Instance Agent

<J_PREFIX>_<SAPSID>_<INSTANCE_NAME_ERS>_ers
Resource
Type
Floating
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME>_<NODENAME_PRIMA
RY>
Group
RY>_SRV
Group
RY>_sapstartsrv
Fixed
RY>_AS
Group
RY>_as
Fixed
<J_PREFIX>_<SAPSID>_<INSTANCE_NAME>_<NODENAME_ADDIT
IONAL>
Group
IONAL>_SRV
Group
IONAL>_sapstartsrv
Fixed
IONAL>_AS
Group
IONAL>_as
Fixed
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER_saprouter
Group
Floating
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER_ip
Floating
<ROUT_PREFIX>_<SAPSID>_SYS_ROUTER
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>
Group
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_SRV
Group
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_ip
Floating
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_sap
startsrv
Floating
- 41 -
Name
SAP WEB
Dispatcher group
SAP WEB
Dispatcher
Host Agent Group
Host Agent
Resource
Type
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_WD
Group
<WD_PREFIX>_<SAPWEBDISP_SID>_<INSTANCE_NAME_WD>_sap
webdisp
Floating
SAP_HOST_AGENT_<NODENAME>
Group
SAP_HOST_AGENT_<NODENAME>_ha
Fixed
The namings of the SAProuter and the SAP WEB dispatcher are the same for the
ABAP and the JAVA policy, refer to Table 4 on page 33.
Table 7: Description and examples of placeholders for JAVA resource names
Tag
<J_PREFIX>
<ROUT_PREFIX>
<WD_PREFIX>
<SAPSID>
<SAPWEBDISP_SID>
<INTERFACENAME>
<NODENAME_PRIMARY>
<NODENAME_ADDITIONAL>
<NODENAME_1>
<NODENAME_2>
<INSTANCE_NAME>
<INSTANCE_NAME_ERS>
<INSTANCE_NAME_WD>
Description
Prefix for resources, has to be specified
in policy. Use a meaningful value to
easily identify resources later.
SAP System SID
Example
JAVA_XI
LOP
Name of a network interface

eth0
Hostname of the node on which the AS is sapnode01
running
Hostnames of the node on which the
sapnode01
ASCS Central Services and the Enqueue
Replication Server are allowed to run
DVEBMGS01
SAP Application Server Instance Name
D02
SAP Enqueue Replication Server
ERS10
Instance Name
SAP Web Dispatcher Instance Name
WD00
The Java SAP Central Services group

The Java SCS group always contains five floating resources: a Service IP, the
Instance Agent resource, the Java Enqueue and Message Servers (ES and MS) and
the SAP Gateway. All are tied together by "StartAfter" (SA) and "StopAfter" (SO)
relationships. When the SCS group is started, the IP resource is started first. Once the
IP resource is online, the Instance Agent resource is started next, followed by the
Enqueue Server, the Message Server and the SAP gateway. All resoures are
contained in collocated groups, so they will always be started on the same node.
All resources are mandatory group members. No restart is attempted by System
Automation for Multiplatforms if one of the resources fail, but a failover of the
whole group is triggered instead.
- 42 -
The Java Enqueue Replication Server group

The Java Enqueue Replication Server group contains three mandatory floating
resources: a ServiceIP, the Instance Agent resource and the Java Enqueue Replication
Server (ERS) itself. All are tied together by "StartAfter" (SA) and "StopAfter" (SO)
relationships. When the Java Enqueue Replication Server group is started, the
ServiceIP is started first, followed by Instance Agent and the Java Enqueue
Replication Server.
Parts of the ABAP and Java policies with the same behavior
The following paragraphs describe parts of the ABAP and Java policy that show the
same behavior and are automated equally, independent of whether they are part of a
ABAP or a Java policy.
The ABAP and Java Application Server (AS) groups
The application servers are implemented as fixed resources in the automation policy,
because moving an AS instance to another node might cause a long downtime for the
AS. Since the SAP architecture allows to run more than one AS, it is far better to run
at least two AS on different hardware to have the necessary AS redundancy.
Each of the application server groups contains an Instance Agent resource and a fixed
application server (AS) resource as mandatory members. The application servers are
in separate groups in order to not affect each other. All application server resources
have a "StartAfter" relationships to their Message Server, because the Message
Server must be online during startup of an application server. The application server
must read the license key from the Message Server, otherwise, a logon to the AS is
not possible (which will also inhibit monitoring of the application server).
It is not required to restart an application server in case of a failure of the Enqueue
Server or Message Server. The application server reconnects to the Message Server
automatically.
Like the Primary Application Server group, Additional Application Server groups
contain an Instance Agent resource and one application server (AS) as mandatory
members.
The start and stop of application servers, especially the Java application servers, can
take a long time. Therefore, the start and stop command timeouts are recommended
to be set to a value between 300 seconds and 500 seconds, depending on ABAP or
Java AS.
The ABAP and Java SAProuter group
The SAProuter program is a SAP utility that controls access to SAP systems. The
SAProuter group contains two floating resources:
SAProuter
Service IP address
Both are tied together by StartAfter and StopAfter relationships If you start the
SAProuter group, the IP resource is started first, followed by the SAProuter resource
itsself. All resoures are contained in a collocated group, so they will always be
started on the same node.
- 43 -
The ABAP and Java SAP Web Dispatcher group

The SAP Web Dispatcher program is an SAP utility that controls Web access for SAP
ABAP and Java systems. The SAP Web Dispatcher group contains three floating
resources:
SAP Web Dispatcher
Service IP address
SAP Web Dispatcher Instance Agent (sapstartsrv)
All are tied together by StartAfter and StopAfter relationships If you start the SAP
Web Dispatcher group, the IP resource is started first, followed by the Instance Agent
resource and the Web Dispatcher resource itsself. All resoures are contained in a
collocated group, so they will always be started on the same node.
The Host Agent groups
A SAP Host Agent is running on each cluster node that is able to host SAP servers
and instances. With System Automation for Multiplatforms each of these Host
Agents is modelled as a fixed resources in its own resource group. No dependencies
exist to other SAP servers and instances.
Policy parameters
The following paragraphs list all parameters that have to be specified for the different
policy options. A HTML file containing all parameter descriptions and all currently
defined values is generated each time the wizard is started and finished using the 0
selection option. For more information, refer to Terminating the wizard on page
nnn.
SAP ABAP Central Services (ASCS) -Enqueue Replication Server (ERS)
HA policy (ABAP)
Table 8: ABAP policy parameters
#
Parameter description
Value type
Enter the name of your SA MP domain.
String
Note: Value harvesting is provided for this parameter.

Provide the name of an existing SA MP domain. The SA MP
domain will host the SAP resources that will be configured with this
template.
2
Select the IP version used in the SAP environment.

Depending on the IP version, either a NetMask for IPv4 or a
NetPrefix for IPv6 has to be specified.
- 44 -
One of the
following values:
IPv4
IPv6
Value
Value type
Specify the existing SAP system ID (SID).
String
Minimum number
of characters: 3,
maximum
number of
characters: 3
(plus additional
value checking)
The SAP system ID consists of 3 characters and is configured

during the SAP installation.
Specify your SAP instance owner user name.

Value
String (plus
additional value
checking)
The default SAP instance owner user's name is composed of the

SAP SID (in lower case) and the suffix "adm".
5
Enter your desired prefix for all ABAP resources.
String
This prefix will be used as a prefix for all SA MP resources that

cover ABAP, for example "SAP_ABAP". For later operational tasks,
the prefix can be used to start and stop resources with the same
prefix with one single command. You may consider to encode the
SAP solution name, e.g. PI, ECC or SCM, which would result in a
prefix like "PI_ABAP".
6
Enter the nodes where you want to automate your SAP Central
Services Instance for ABAP (ASCS).
List of values,
value type for
each value:

These nodes must be listed by the SA MP command "lsrpnode" for
the specified domain. You can use either the long or the short
name for a node. An ASCS resource will be created for each of the
specified nodes.
7
Specify the instance name of the SAP Central Services Instance

for ABAP (ASCS).
Hostname or IP
version 4
address (plus
additional value
checking)
String
Minimum number
of characters: 6,
maximum
This instance name is used for the instance directory that contains number of
all necessary files for the ASCS instance. A sample instance name characters: 6
is 'ASCS00'.
Specify the virtual hostname for the Central Services Instance for
ABAP (ASCS).
This hostname will be used as a virtual hostname for the Central
Services Instance for ABAP (ASCS). Enter the same virtual
hostname that was used for 'sapinst SAPINST_USE_HOSTNAME=virt_hostname-' during the ASCS installation.
- 45 -
Hostname
SAP_ABAP
Value type
This parameter will be ignored unless all following conditions are

fulfilled:
IP version 4
address
Value
- Parameter # 2 has the value "IPv4"

Specify the virtual IPv4 address for the SAP Central Services
Instance for ABAP (ASCS).
This IPv4 address will be used as a virtual IP address for the
floating ASCS instance.
10

fulfilled:
IP version 6
address

Instance for ABAP (ASCS).
floating ASCS instance.
11

fulfilled:
IP version 4
address

Specify the netmask for the virtual ASCS instance IP address.
Enter the netmask for the subnet of the virtual ASCS instance IP
address. An example for a netmask is "255.255.255.0".
12

fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the ASCS instance virtual IP address.
Enter the NetPrefix for the ASCS instance virtual IP address. An
example for a NetPrefix is 80.
13
Specify the network interface name where your ASCS instance

String (plus
virtual IP address is activated on each node as alias. The following additional value
network interfaces are available on your local system:
checking)
(remaining part of description is harvested from running system)
The network interface specifies to which network interface on each
node the virtual ASCS instance IP address can be bound, for AIX
an example is "en0", for Linux, an example is "eth0". The same
network interface name needs to be available on all nodes where
the ASCS instance will be automated.
14
Specify the instance name of the ABAP ERS instance.

String
Minimum number
of characters: 5,
This instance name is used for the instance directory that contains maximum
all necessary files for the ABAP ERS instance. A sample instance number of
name is 'ERS12'.
characters: 5
(plus additional
value checking)
- 46 -
255.255.255.0
Value type
15
Specify the virtual hostname of the ABAP ERS instance.
String
Value

This hostname will be used as a virtual hostname for the ABAP
ERS instance. Enter the same virtual hostname that was used for
'sapinst SAPINST_USE_HOSTNAME=-virt_hostname-' during the
ABAP ERS installation.
16

fulfilled:
IP version 4
address

Specify the virtual IPv4 address for the ABAP enqueue replication
server (ABAP ERS).
ABAP enqueue replication server (ABAP ERS) instance.
17

fulfilled:
IP version 6
address

Specify the virtual IPv6 address for the ABAP enqueue replication
server (ABAP ERS).
ABAP enqueue replication server (ABAP ERS) instance.
18

fulfilled:
IP version 4
address

Specify the netmask for the virtual ABAP ERS instance IP address.
Enter the netmask for the subnet of the virtual ABAP ERS instance
IP address. An example for a netmask is "255.255.255.0".
19

fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the ABAP ERS instance virtual IP address.
Enter the NetPrefix for the ABAP ERS instance virtual IP address.
An example for a NetPrefix is 80.
20
Specify the network interface name where your ABAP ERS

String (plus
instance virtual IP address is activated on each node as alias. The additional value
following network interfaces are available on your local system:
checking)
The network interface specifies to which network interface one
each node the virtual ABAP ERS instance IP address can be
bound, for AIX an example is "en0", for Linux, an example is
"eth0". The same network interface name needs to be available on
all nodes where the ABAP ERS instance will be automated.
- 47 -
255.255.255.0
Value type
21
Do you want to automate the ABAP application servers?
{yes|no}
Value
The ABAP application servers host the applications and serve the
user requests. Automation of the ABAP application servers is
recommended, but optional. Choose yes if you want to automate
the ABAP application servers.
21.1 Optional; a value for this parameter is only required if parameter
#21 has the value "yes".
Enter the nodes where you want to automate the application
servers.
List of values,
value type for
each value:
Hostname or IP
version 4
address

name for a node. An SA MP application server resource will be
created for each of the specified nodes.
This parameter must have the same number of values as the
following parameters:
- Parameter # 21, nested parameter 2
Specify all instance names of your application servers. Use the
same order as for the nodes in one of the previous questions.
List of values,
value type for
each value:
String (plus
additional value
checking)
In this policy, the instance names are used to identify the instance
directory that contains all necessary files for the application server.
The naming syntax is DVEBMGS-InstanceID- or D-InstanceID-.
Use the same order as for the nodes in one of the previous
questions, i.e. if you specified node01 first, then you now have to
specify the instance directory for your application server on
node01 first.
Enter the start timeout value for your ABAP application servers.
The start timeout attribute determines the maximum run time in
seconds of the StartCommand. If the StartCommand does not
return within the timeout period, System Automation for
Multiplatforms kills the StartCommand with the SIGKILL command
and logs a message to the system log of the node. The default
value for the ABAP application servers is 300.
- 48 -
Numeric
300

Value type
Value
Numeric
300
Enter the stop timeout value for your ABAP application servers.
With the stop timeout attribute you specify the amount of time in
seconds the stop command for your application servers allowed to
run before it is killed by Tivoli System Automation. The default
value for the ABAP application servers is 300 seconds.
22

fulfilled:
{yes|no}
- Parameter # 21 has the value "yes"

Did you configure a virtual hostname during installation for at least
one of the application servers specified in the previous question?
Choose yes if at least one of the application servers has been
installed with a virtual hostname.
Specify the virtual hostname for each application server. Use the
same order as for the nodes in one of the previous questions. If
you installed one of the application servers without a virtual
hostname, specify the system hostname instead.
List of values,
value type for
each value:
Hostname

This hostname will be used as a virtual hostname for an
application server. Enter the same virtual hostname that was used
for 'sapinst SAPINST_USE_HOSTNAME=-virt_hostname-' during
the SAP installation. Use the same order as for the nodes in one of
the previous questions, i.e. if you specified node01 first, then you
now have to specify the virtual hostname for your application
server on node01 first.
23
Do you want to automate the SAP Host Agent?
{yes|no}
SAP Host Agent can be used for monitoring and control of SAP
instances and non-SAP instances, operating systems, and
databases.
23.1
Optional; a value for this parameter is only required if parameter

List of values,
value type for
each value:
Enter the nodes where you want to automate the SAP Host Agent.
Hostname or IP
version 4
address

name for a node. An SA MP host agent resource will be created for
each of the specified nodes.
24
Do you want SA MP to automate your SAP router?

SAP router serves as a proxy in a network connection between
SAP systems or between SAP systems and external networks. If
you answer this question with yes, SA MP will create automation
resources for the SAP router.
- 49 -
{yes|no}
#
24.1
Value type
Value

String
SAP_ROUTER
Enter the desired prefix for the SAP router resources.

You are allowed to use the same prefix as for other resources, like
JAVA or ABAP.
24.2

List of values,
value type for
each value:
Enter the nodes where you want to automate the SAP router.
For each of the nodes specified, SA MP will create SAP router

resources.
Hostname or IP
version 4
address (plus
additional value
checking)

fulfilled:
IP version 4
address
24.3

Specify the virtual IPv4 address that clients will use to connect to
the SAP router.
This virtual IPv4 address is used to reach the SAP router,
independent of the system it is currently running on.
24.4

fulfilled:
IP version 6
address

the SAP router.
24.5

fulfilled:
Specify the netmask for the SAP router virtual IP address.
Enter the netmask for the subnet of the SAP router virtual IP
- 50 -
IP version 4
address
255.255.255.0
Value type
24.6 This parameter will be ignored unless all following conditions are
fulfilled:
Value
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the SAP router virtual IP address.
Enter the NetPrefix for the SAP router virtual IP address. An
24.7

String (plus
additional value
checking)
Enter the network interface for the SAP router IP address. The
The available network interface specifies to which network
interfaces the SAP router virtual IP address can be bound, for AIX
the SAP router will be automated.
24.8

String
Specify the fully qualified SAP router routing table filename.

Use the location of the NFS device that contains the routing table
file. An example for the fully qualified SAP router routing table
filename is /usr/sap/-SAPSID-/SYS/global/saprouttab.
25
Do you want SA MP to automate the SAP Web dispatcher?
{yes|no}
The SAP Web dispatcher receives HTTP(s) requests from the

internet that are targeted for your SAP system. If you answer this
question with yes, SA MP will create automation resources for the
SAP Web dispatcher.
25.1

String
Enter the desired prefix for the SAP Web Dispatcher resources.
JAVA or ABAP.
25.2

Enter the nodes where you want to automate the SAP
Webdispatcher.
Nodes where the SAP Webdispatcher is configured and where it
will be automated.
- 51 -
List of values,
value type for
each value:
Hostname or IP
version 4
address (plus
additional value
checking)
SAP_WDISP
#
25.3
Value type

String (plus
additional value
checking)
Specify the SAP system ID (SAPSID) for the SAP Web dispatcher.
The SAP system ID (SAPSID) for the SAP Web dispatcher is
required to identify the SAP Web dispatcher correctly.
25.4

String (plus
additional value
checking)
Specify the instance owner username that will be used to execute

the start, stop and monitor commands for SAP Web dispatcher
resources.
The instance owner username is composed of the SAP Web
Dispatcher SID and the suffix "adm".
25.5

String
Specify the instance name of the SAP web dispatcher instance,

i.e. 'W00'.
This instance name is used for the instance directory that contains
all necessary files for the SAP web dispatcher instance.
Hostname
Specify the virtual hostname for the SAP Web dispatcher.

This hostname will be used as a virtual hostname for the SAP Web
dispatcher. Enter the same virtual hostname that was used for
SAP installation. Use the same order as for the nodes in one of the
previous questions, i.e. if you specified node01 first, then you now
have to specify the virtual hostname for your application server on
node01 first.
25.7

fulfilled:
the SAP web dispatcher.
This virtual IPv4 address is used to reach the SAP Web
dispatcher, independent of the system it is currently running on.
- 52 -
IP version 4
address
Value
#
25.8
Value type

fulfilled:
IP version 6
address
Value

25.9

fulfilled:
IP version 4
address

Specify the netmask for the SAP Web dispatcher virtual IP
address.
Enter the netmask for the subnet of the SAP Web dispatcher
virtual IP address. An example for a netmask is "255.255.255.0".
fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the SAP Web dispatcher IP address.
Enter the NetPrefix for the SAP Web dispatcher IP address. An
Specify the network interface on which SAP web dispatcher virtual
IP address is activated on each node as alias. The following
interfaces the SAP web dispatcher virtual IP address can be
all nodes where the SAP Web dispatcher instance will be
automated.
- 53 -
String (plus
additional value
checking)
255.255.255.0
Value type
26

fulfilled:
{yes|no}
Value

If your database is automated with SA MP in the same cluster, do
you want to create startAfter relationships for your application
servers?
A startAfter relationship will be created for each Application Server.
If you want to create startAfter relationships to a database, the
database needs to be automated in the same cluster as SAP.
26.1

String
Enter the name of your floating SA MP database resource.

This is the name of your floating SA MP database resource, i.e.
"db2_db2ax0_0-rs".
SAP JAVA Central Services (SCS) -Enqueue Replication Server (ERS)

HA policy (Java)
Table 9: Java policy parameters
#
Value type
Enter the name of your SA MP domain.
String

Provide the name of an existing SA MP domain. The SA MP
domain will host the SAP resources that will be configured with
this template.
2
Select the IP version used in the SAP environment.

Depending on the IP version, either a NetMask for IPv4 or a
NetPrefix for IPv6 has to be specified.
IPv4
IPv6
Specify the existing SAP system ID (SID).
String
Minimum number
of characters: 3,
maximum
number of
characters: 3
(plus additional
value checking)
The SAP system ID consists of 3 characters and is configured

during the SAP installation.
One of the
following values:
Specify your SAP instance owner user name.

The default SAP instance owner user's name is composed of the
SAP SID (in lower case) and the suffix "adm".
- 54 -
String (plus
additional value
checking)
Value
Value type
Value
Enter your desired prefix for all JAVA resources.
String
SAP_JAVA
This prefix will be used as a prefix for all SA MP resources that

cover SAP JAVA components. For later operational tasks, the
prefix can be used to start and stop resources with the same prefix
with one single command. You may consider to encode the SAP
solution name, e.g. EP (Enterprise Portal), which would result in a
prefix like "PE_JAVA".
6
Enter the nodes where you want to automate your SAP Central
Services Instance for JAVA (SCS).
List of values,
value type for
each value:

Hostname or IP
These nodes must be listed by the SA MP command "lsrpnode" for version 4 address
(plus additional
name for a node. A SCS resource will be created for each of the
value checking)
specified nodes.
7
Specify the instance name of the SAP Central Services Instance

for JAVA (SCS).
String
Minimum number
of characters: 5,
maximum
This instance name is used for the instance directory that contains number of
all necessary files for the SCS instance. A sample instance name characters: 5
is 'SCS01'.
Specify the virtual hostname for the Central Services Instance for Hostname
JAVA (SCS). Enter the same virtual hostname that was used for
SAP installation.
This hostname will be used as a virtual hostname for the Central
Services Instance for JAVA (SCS).

fulfilled:
IP version 4
address

Instance for JAVA (SCS).
floating SAP Central Services Instance for JAVA (SCS).
10

fulfilled:
Instance for JAVA (SCS).
floating SAP Central Services Instance for JAVA (SCS).
- 55 -
IP version 6
address
Value type
Value
11

fulfilled:
IP version 4
address
255.255.255.0

Specify the netmask for the virtual JAVA SCS instance IP address.
Enter the netmask for the subnet of the JAVA SCS instance IP
12

fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the JAVA SCS instance virtual IP address.
Enter the NetPrefix for the JAVA SCS instance virtual IP address.
13
Specify the network interface name where your JAVA SCS

String (plus
checking)
The network interface specifies on which network interface on
each node the virtual JAVA SCS instance IP address can be
bound to, for AIX an example is "en0", for Linux, an example is
all nodes where the JAVA SCS instance will be automated.
14
Specify the instance name of the JAVA ERS instance.
String
Minimum number
of characters: 5,
This instance name is used for the instance directory that contains maximum
all necessary files for the JAVA ERS instance. A sample instance
number of
name is 'ERS11'.
characters: 5
(plus additional
value checking)
15
Specify the virtual hostname of SAP JAVA enqueue replication

server (JAVA ERS).
String

This hostname will be used as a virtual hostname for the JAVA
ERS instance. Enter the same virtual hostname that was used for
JAVA ERS installation.
16

fulfilled:
Specify the virtual IPv4 address for the JAVA enqueue replication
server (JAVA ERS).
This IPv4 address will be used as a virtual IP address for the JAVA
enqueue replication server (JAVA ERS) instance.
- 56 -
IP version 4
address
Value type
17

fulfilled:
IP version 6
address
Value

Specify the virtual IPv6 address for the JAVA enqueue replication
server (JAVA ERS).
This IPv6 address will be used as a virtual IP address for the JAVA
enqueue replication server (JAVA ERS) instance.
18

fulfilled:
IP version 4
address

Specify the netmask for the virtual JAVA ERS instance IP address.
Enter the netmask for the subnet of the virtual JAVA ERS instance
IP address. An example for a netmask is "255.255.255.0".
19

fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the JAVA ERS instance virtual IP address.
Enter the NetPrefix for the JAVA ERS instance virtual IP address.
20
Specify the network interface name where your JAVA ERS

String (plus
checking)
The network interface specifies to which network interface one
each node the virtual JAVA ERS instance IP address can be
all nodes where the JAVA ERS instance will be automated.
21
Do you want to automate the JAVA application servers?

Automation of the JAVA application servers is recommended, but
optional. Choose yes if you want to automate the JAVA application
servers.
- 57 -
{yes|no}
255.255.255.0
#
21.1
Value type

List of values,
value type for
each value:
Enter the nodes where you want to automate the application

servers.
Value
Hostname or IP
version 4 address

name for a node. An SA MP application server resource will be
created for each of the specified nodes.
21.2

Specify all instance names of your application servers. Use the
same order as for the nodes in one of the previous questions.
List of values,
value type for
each value:
String (plus
additional value
checking)
In this policy, the instance names are used to identify the instance
directory that contains all necessary files for the application server.
The naming syntax is J-InstanceID- or JC-InstanceID-. Use the
same order as for the nodes in one of the previous questions, i.e.
if you specified node01 first, then you now have to specify the
instance directory for your application server on node01 first.
21.3

Numeric
500
Numeric
360
Enter the start timeout value for your JAVA application servers.
The start timeout attribute determines the maximum run time in
seconds of the StartCommand. If the StartCommand does not
return within the timeout period, System Automation for
Multiplatforms kills the StartCommand with the SIGKILL command
and logs a message to the system log of the node. The default
value for the JAVA application servers is 500.
21.4

Enter the stop timeout value for your JAVA application servers.
With the stop timeout attribute you specify the amount of time in
seconds the stop command for your application servers allowed to
run before it is killed by Tivoli System Automation. The default
value for the JAVA application servers is 360 seconds.
- 58 -
Value type
22

fulfilled:
{yes|no}
Value

Did you configure a virtual hostname during installation for at least
one of the application servers specified in the previous question?
Choose yes if at least one of the application servers has been
installed with a virtual hostname.
22.1

Specify the virtual hostname for each application server. Use the
same order as for the nodes in one of the previous questions. If
you installed one of the application servers without a virtual
hostname, specify the system hostname instead.
List of values,
value type for
each value:
Hostname

This hostname will be used as a virtual hostname for an
application server. Enter the same virtual hostname that was used
the SAP installation. Use the same order as for the nodes in one
of the previous questions, i.e. if you specified node01 first, then
you now have to specify the virtual hostname for your application
23
Do you want to automate the SAP Host Agent?
{yes|no}
SAP Host Agent can be used for monitoring and control of SAP
instances and non-SAP instances, operating systems, and
databases.
23.1

List of values,
value type for
each value:
Enter the nodes where you want to automate the SAP Host Agent.
Hostname or IP
version 4 address

name for a node. An SA MP host agent resource will be created
for each of the specified nodes.
24
Do you want SA MP to automate your SAP router?
{yes|no}
SAP router serves as a proxy in a network connection between

SAP systems or between SAP systems and external networks. If
you answer this question with yes, SA MP will create automation
resources for the SAP router.
24.1

Enter the desired prefix for the SAP router resources.
JAVA or ABAP.
- 59 -
String
SAP_ROUTER
#
24.2
Value type

List of values,
value type for
each value:
Value
Enter the nodes where you want to automate the SAP router.
For each of the nodes specified, SA MP will create SAP router
resources.
24.3

fulfilled:
Hostname or IP
version 4 address
(plus additional
value checking)
IP version 4
address

the SAP router.
24.4

fulfilled:
IP version 6
address

the SAP router.
24.5

fulfilled:
IP version 4
address

Specify the netmask for the SAP router virtual IP address.
Enter the netmask for the subnet of the SAP router virtual IP
24.6

fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the SAP router virtual IP address.
Enter the NetPrefix for the SAP router virtual IP address. An
- 60 -
255.255.255.0
#
24.7
Value type

String (plus
additional value
checking)
Value
Enter the network interface for the SAP router IP address. The
interfaces the SAP router virtual IP address can be bound, for AIX
the SAP router will be automated.
24.8

String
Specify the fully qualified SAP router routing table filename.

Use the location of the NFS device that contains the routing table
file. An example for the fully qualified SAP router routing table
filename is /usr/sap/-SAPSID-/SYS/global/saprouttab.
25
Do you want SA MP to automate the SAP Web dispatcher?
{yes|no}
The SAP Web dispatcher receives HTTP(s) requests from the

internet that are targeted for your SAP system. If you answer this
question with yes, SA MP will create automation resources for the
SAP Web dispatcher.
25.1

String
Enter the desired prefix for the SAP Web Dispatcher resources.
JAVA or ABAP.
25.2

Enter the nodes where you want to automate the SAP
Webdispatcher.
List of values,
value type for
each value:
Hostname or IP
version 4 address
(plus additional
value checking)
Nodes where the SAP Webdispatcher is configured and where it

will be automated.
25.3

Specify the SAP system ID (SAPSID) for the SAP Web dispatcher.
The SAP system ID (SAPSID) for the SAP Web dispatcher is
required to identify the SAP Web dispatcher correctly.
- 61 -
String (plus
additional value
checking)
SAP_WDISP
#
25.4
Value type

String (plus
additional value
checking)
Specify the instance owner username that will be used to execute

the start, stop and monitor commands for SAP Web dispatcher
resources.
The instance owner username is composed of the SAP Web
Dispatcher SID and the suffix "adm".
25.5

String
Specify the instance name of the SAP web dispatcher instance,

i.e. 'W00'.
This instance name is used for the instance directory that contains
all necessary files for the SAP web dispatcher instance.
25.6

Hostname
Specify the virtual hostname for the SAP Web dispatcher.

This hostname will be used as a virtual hostname for the SAP
Web dispatcher. Enter the same virtual hostname that was used
the SAP installation. Use the same order as for the nodes in one
of the previous questions, i.e. if you specified node01 first, then
you now have to specify the virtual hostname for your application
25.7

fulfilled:
IP version 4
address

25.8

fulfilled:
- 62 -
IP version 6
address
Value
#
25.9
Value type
Value

fulfilled:
IP version 4
address
255.255.255.0

Specify the netmask for the SAP Web dispatcher virtual IP
address.
Enter the netmask for the subnet of the SAP Web dispatcher
virtual IP address. An example for a netmask is "255.255.255.0".
fulfilled:
Numeric
Minimum value:
0, maximum
value: 128

Enter the NetPrefix for the SAP Web dispatcher IP address.
Enter the NetPrefix for the SAP Web dispatcher IP address. An
String (plus
additional value
checking)
Specify the network interface on which SAP web dispatcher virtual

IP address is activated on each node as alias. The following
interfaces the SAP web dispatcher virtual IP address can be
all nodes where the SAP Web dispatcher instance will be
automated.
26

fulfilled:
{yes|no}

If your database is automated with SA MP in the same cluster, do
you want to create startAfter relationships for your application
servers?
A startAfter relationship will be created for each Application Server.
If you want to create startAfter relationships to a database, the
database needs to be automated in the same cluster as SAP.
26.1

Enter the name of your floating SA MP database resource.
This is the name of your floating SA MP database resource, i.e.
"db2_db2ax0_0-rs".
- 63 -
String
With System Automation for Multiplatforms 3.next all existing SAP HA 3.2style policies can still be used and activated as long as they are in the form
of a complete XML policy file, that was created with System Automation
for Multiplatforms 3.2 from a former SAP HA policy template of the same
version. These existing SAP HA policies are usually stored in the System
Automation for Multiplatforms policy pool and are not erased or overwritten
when a new System Automation for Multiplatforms release is installed. The
Start/Stop/Monitor scripts used by those 3.2-style SAP HA policies are still
delivered with System Automation for Multiplatforms Release 3.next, so they
do not have to be saved before migrating.
Migration steps
Overview
Migration considerations
Migrating the SAP HA policy
The SAP HA automation policy shipped with System Automation for Multiplatforms
3.next incorporates major changes in the way the components of a SAP solution are
controlled and managed. The new SAP HA policy makes use of new interfaces and
conforms to advisories made by SAP.
Because of these changes, a SAP HA policy generated with System Automation for
Multiplatforms 3.next will show major differences when compared to a 3.2-style
SAP HA policy. Thus the migration process is essentially a way of a smoothly
replacing the former policy with a new policy that conforms to the changed methods
of controlling a SAP solution.
These are the special considerations that must be observed when migrating an SAP
HA cluster and policy from the previous version of System Automation for
Multiplatforms Release 3.2.
The former SAP HA policy template files and their related snippets are
replaced by new versions when System Automation for Multiplatforms
Release 3.next is installed. The new SAP HA policy wizard contained in SA
MP 3.next will not work with the former policy templates. So you cannot use
the old template files to generate or change SAP HA policies in the 3.2
style, even if you saved these template files to another location before
installing System Automation for Multiplatforms 3.next.
Only SAP NetWeaver versions 7.0 or higher with kernel versions 7.20 or
higher are supported by the SAP HA solution provided by System
Automation for Multiplattforms 3.next.
SAP solutions that are based on a SAP Central Instance (CI) implementation
are no longer supported by the SAP HA solution. You need to have a SAP
Central Services (CS) setup.
These are the steps to follow when migrating your SAP HA cluster to System
Automation for Multiplatforms 3.next:
- 64 -
1. Upgrade your SAP cluster to System Automation for Multiplatforms 3.next

on page 65.
2. Granting System Automation for Multiplatforms access for the
<sapsid>adm on page 65.
3. Create a new SAP HA automation policy on page 65.
4. Change SAP profile parameters on page 65.
5. Enable the SAP HA connector on page 66.
6. Activate and verify the new System Automation for Multiplatforms 3.next
SAP HA policy on page 66.
Upgrade your SAP cluster to System Automation for Multiplatforms
3.next
For upgrading your cluster to the new version of System Automation for
Multiplatforms follow the steps described in the chapter Migrating IBM Tivoli
Automation. You might either migrate the entire domain or use the node-by-node
approach.
The System Automation for Multiplatforms upgrade will not interfere with the
currently running SAP HA policy, the policy will remain loaded. But for safety
reasons be sure to have the complete XML automation policy file for your SAP
HA setup available as a backup, either stored in the System Automation for
Multiplatforms policy pool(s) or in another location. The former complete XML
automation policy is also working with the new System Automation for
Multiplatforms version.
Granting System Automation for Multiplatforms access for the
<sapsid>adm
The userid <sapsid>adm must have the authority to perform System Automation for
Multiplatforms commands which are launched by the SAP HA interface.
Refer to chapter Setting up security for System Automation for Multiplatforms
clusters in the IBM Tivoli System Automation for Multiplatforms Administrator's
and User's Guide to setup the non-root security for the <sapsid>adm userid. It is
sufficient to use the role sa_operator.
Create a new SAP HA automation policy
Use the policy wizard contained in System Automation for Multiplatforms 3.next to
create the new-style SAP HA automation policy as described in the next chapter
Using the wizard to configure and activate the SAP HA solution.
The policy wizard will not automatically extract configuration information from your
former SAP HA policy (template) files. You have to reenter all values manually, but
you are assisted by the harvesting functions of the new policy wizard. In addition you
can refer to the parameter and value summary, that was created in HTML format at
the time you configured your former 3.2-style SAP HA policy. The file should
have been saved into the policy pool with the same name as the former template file
and the added extension .html.
Change SAP profile parameters
Before the new SAP HA policy can be activated, you have to adjust some settings in
- 65 -
your SAP profiles:
Set the SAP profile parameter for EN and ERS to Start_Program_<NR>.

Do NOT set it Restart_Program, otherwise proper recovery by System
Automation for Multiplatforms will not work.
Set the SAP profile parameters for all other servers to

Restart_Program_<NR>.
Enable the SAP HA connector

After System Automation for Multiplatforms has been installed on all cluster nodes,
the SAP HA Connecter must be configured in the SAP profiles. It is sufficient to put
the required entries into the default profile.
Please refer to Enabling the SAP HA Connector on page 30 on how to add the SAP
HA connector for your platform.
Activate and verify the new System Automation for Multiplatforms
3.next SAP HA policy
You should now be ready to activate and verify your new SAP HA policy:
Deactivate your old policy using sampolicy -d command
Activate the new SAP HA policy as described in chapter 22 (???) Using the
wizard to configure and activate the policy
Verify the policy as described in the following paragraphVerifying the SAP

HA solution on page 67.
Using the wizard to configure and activate the SAP HA solution

Each SAP HA policy consists of a policy template that is tailored by using the
sampolicy wizard. To configure the template, run the following command:
sampolicy w templateFileName
Depending on the SAP HA setup option that you choose, specify one of the
following fully qualified XML template file names:
Table 10: Location for the SAP HA XML template files
SAP HA setup
XML template file
ABAP
Java
/usr/sbin/rsct/sapolicies/sap/sap_ABAP_v41.tmpl.xml
/usr/sbin/rsct/sapolicies/sap/sap_Java_v41.tmpl.xml
You must configure a policy pool before running the wizard. The wizard will then
store all modifications to the policy pool. If you set your policy pool to
/etc/myPolicyPool, a wizard run using
sampolicy -w /usr/sbin/rsct/sapolicies/sap/sap_ABAP_v41.tmpl.xml
stores the results to

/etc/myPolicyPool/sap_ABAP_v41.tmpl.xml
The next time you invoke the wizard, use the file stored in the policy pool. With the
- 66 -
example above, invoking the wizard for the second time would look like this:
sampolicy -w /etc/myPolicyPool/sap_ABAP_v41.tmpl.xml
For a detailed description of the sampolicy wizard, refer to chapter 22 (???), Using
the wizard to configure and activate the policy, on page nnn.
Verifying the SAP HA solution

In this chapter we provide the information on how to verify your SAP HA solution.
Start your entire SAP system: Starting and stopping SAP HA
Set up your test environment: Failover scenarios on page 68
Starting and stopping SAP HA

You can start your entire SAP system by issuing the command:
chrg -o online -s "Name like %"
Enter the following command to display your SAP ABAP or Java HA policy:
lssam -noequ
Output:
root@node1 ~# lssam -noequ
Offline IBM.ResourceGroup:SAP_ABAP_AX6_ASCS00 Nominal=Offline
|- Offline IBM.ResourceGroup:SAP_ABAP_AX6_ASCS00_ASCS Nominal=Offline
|- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_en
|- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_en:node1
'- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_en:node2
'- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_ms
|- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_ms:node1
'- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_ms:node2
'- Offline IBM.ResourceGroup:SAP_ABAP_AX6_ASCS00_SRV Nominal=Offline
|- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_sapstartsrv
|- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_sapstartsrv:node1
'- Offline IBM.Application:SAP_ABAP_AX6_ASCS00_sapstartsrv:node2
'- Offline IBM.ServiceIP:SAP_ABAP_AX6_ASCS00_ip IP=9.152.135.234
|- Offline IBM.ServiceIP:SAP_ABAP_AX6_ASCS00_ip:node1
'- Offline IBM.ServiceIP:SAP_ABAP_AX6_ASCS00_ip:node2
Offline IBM.ResourceGroup:SAP_ABAP_AX6_D03_node2 Nominal=Offline
|- Offline IBM.ResourceGroup:SAP_ABAP_AX6_D03_node2_AS Nominal=Offline
'- Offline IBM.Application:SAP_ABAP_AX6_D03_node2_as:node2
'- Offline IBM.ResourceGroup:SAP_ABAP_AX6_D03_node2_SRV Nominal=Offline
'- Offline IBM.Application:SAP_ABAP_AX6_D03_node2_sapstartsrv:node2
Offline IBM.ResourceGroup:SAP_ABAP_AX6_DVEBMGS02_node1 Nominal=Offline
|- Offline IBM.ResourceGroup:SAP_ABAP_AX6_DVEBMGS02_node1_AS Nominal=Offline
'- Offline IBM.Application:SAP_ABAP_AX6_DVEBMGS02_node1_as:node1
'- Offline IBM.ResourceGroup:SAP_ABAP_AX6_DVEBMGS02_node1_SRV Nominal=Offline
'- Offline IBM.Application:SAP_ABAP_AX6_DVEBMGS02_node1_sapstartsrv:node1
Offline IBM.ResourceGroup:SAP_ABAP_AX6_ERS10 Nominal=Offline
|- Offline IBM.ResourceGroup:SAP_ABAP_AX6_ERS10_AERS Nominal=Offline
'- Offline IBM.Application:SAP_ABAP_AX6_ERS10_ers
|- Offline IBM.Application:SAP_ABAP_AX6_ERS10_ers:node1
'- Offline IBM.Application:SAP_ABAP_AX6_ERS10_ers:node2
'- Offline IBM.ResourceGroup:SAP_ABAP_AX6_ERS10_SRV Nominal=Offline
|- Offline IBM.Application:SAP_ABAP_AX6_ERS10_sapstartsrv
|- Offline IBM.Application:SAP_ABAP_AX6_ERS10_sapstartsrv:node1
'- Offline IBM.Application:SAP_ABAP_AX6_ERS10_sapstartsrv:node2
'- Offline IBM.ServiceIP:SAP_ABAP_AX6_ERS10_ip IP=9.152.135.235
|- Offline IBM.ServiceIP:SAP_ABAP_AX6_ERS10_ip:node1
'- Offline IBM.ServiceIP:SAP_ABAP_AX6_ERS10_ip:node2
Offline IBM.ResourceGroup:SAP_HOST_AGENT_node1 Nominal=Offline
'- Offline IBM.Application:SAP_HOST_AGENT_node1_ha:node1
Offline IBM.ResourceGroup:SAP_HOST_AGENT_node2 Nominal=Offline
- 67 -
'- Offline IBM.Application:SAP_HOST_AGENT_node2_ha:node2

Offline IBM.ResourceGroup:SAP_ROUTER_AX6_SYS_ROUTER Nominal=Offline
|- Offline IBM.Application:SAP_ROUTER_AX6_SYS_ROUTER_saprouter
|- Offline IBM.Application:SAP_ROUTER_AX6_SYS_ROUTER_saprouter:node1
'- Offline IBM.Application:SAP_ROUTER_AX6_SYS_ROUTER_saprouter:node2
'- Offline IBM.ServiceIP:SAP_ROUTER_AX6_SYS_ROUTER_ip IP=9.152.135.227
|- Offline IBM.ServiceIP:SAP_ROUTER_AX6_SYS_ROUTER_ip:node1
'- Offline IBM.ServiceIP:SAP_ROUTER_AX6_SYS_ROUTER_ip:node2
Offline IBM.ResourceGroup:SAP_WDISP_AW6_W00 Nominal=Offline
|- Offline IBM.ResourceGroup:SAP_WDISP_AW6_W00_WD Nominal=Offline
|- Offline IBM.Application:SAP_WDISP_AW6_W00_sapwebdisp
|- Offline IBM.Application:SAP_WDISP_AW6_W00_sapwebdisp:node1
'- Offline IBM.Application:SAP_WDISP_AW6_W00_sapwebdisp:node2
'- Offline IBM.ResourceGroup:SAP_WDISP_AW6_W00_SRV Nominal=Offline
|- Offline IBM.Application:SAP_WDISP_AW6_W00_sapstartsrv
|- Offline IBM.Application:SAP_WDISP_AW6_W00_sapstartsrv:node1
'- Offline IBM.Application:SAP_WDISP_AW6_W00_sapstartsrv:node2
'- Offline IBM.ServiceIP:SAP_WDISP_AW6_W00_ip IP=9.152.135.228
|- Offline IBM.ServiceIP:SAP_WDISP_AW6_W00_ip:node1
'- Offline IBM.ServiceIP:SAP_WDISP_AW6_W00_ip:node2
Your high availability SAP system is now ready for use.

To stop your entire SAP system use the command:
chrg -o offline -s "Name like %"
Failover scenarios
The scenarios cover both planned outages (normal operation, maintenance) and
unplanned outages (failures). Each scenario should be verified for proper operation.
Test setup
The following scenarios expect the topology to be a cluster with two nodes (node1,
node2). We have "floating" groups for the SAProuter, Web Dispatcher and the
Enqueue and Enqueue Replication servers, and "fixed" groups for each application
server on each node.
You can use the lssam command to monitor the reaction of the system to the actions
taken.
Scenarios
Table 11 on page 69 and Table 12 on page 70 list the important scenarios for planned
and unplanned outages. The preconditions for executing the scenarios are listed
above the "Action", "Command" and "Expected result" columns. Each scenario is
divided into steps, where each steps precondition is the successful completion of the
preceding action. The commands to be executed are listed in the "Command"
column. If you have different namings, you have to adapt the commands accordingly.
The last column of the tables lists the expected result.
See Table 4 on page 33, Table 6 on page 40, and Table 10 on page 66 for a detailed
explanation of the <placeholders> for the resource names within the command
column.
For the command examples in Table 11, replace <x_PREFIX> with the ABAP or
Java prefix depending on whether you have ABAB or Java setup. Also replace
DVEBMSG and D for ABAP application servers with J for Java application
servers.
- 68 -
Table 11: Planned Outages
Scenario
Normal
operation
Maintena
nce
Action
Command
Precondition: All groups offline
Start an SAP
system
chrg -o online -s
"Name like <x_PREFIX>_%"
Stop SAP system

AX6
chrg -o offline -s "Name like

<x_PREFIX>_AX6_%"
(Re-)Start SAP
system AX6
chrg -o online -s "Name like

<x_PREFIX>_AX6_%"
Expected result
ROUTER, WEBDISP,
(A)SCS and
DVEBMGS/J groups
start on node1.
ERS and D/J groups start
on node2.
(A)SCS, ERS,
DVEBMGS/J and D/J
groups stop.
(A)SCS, and ABAP
DVEBMGS/J groups
start on node1.
ERS and D/J groups start
on node2.
All groups stop.
chrg -o offline -s
Stop an SAP
"Name like <x_PREFIX>_%"
system
Precondition:
ROUTER, WEBDISP, (A)SCS, and DVEBMGS/J groups are online on
node1
ERS and D/J groups are online on node2
ROUTER, WEBDISP,
(A)SCS, and
DVEBMGS/J groups
stop.
DVEBMGS/J groups
Move all
have status Failed
resources away
samctrl -u a node1
Offline.
from node1 in
ROUTER and WEBDISP
order to apply
group start on node2.
operating system
(A)SCS group starts on
or hardware
node2.
maintenance.
ERS terminates.
ERS groups sacrificed.
Apply maintenance, reboot, etc.
DVEBMGS/J groups and
samctrl -u d node1
ERS groups start on node1.
rgreq -o stop
Stop and restart
ERS groups stop.
<x_PREFIX>_<SAPSID>_
Enqueue
<INSTANCE_NAME_ERS>
Replication
Server in order to
- 69 -
Scenario
Action
Command
apply SAP
maintenance
(code or profile
changes).
Move Enqueue
Server in order to
apply SAP
maintenance
(code or profile
changes).
Stop and restart
Primary
Application
Server in order to
apply SAP
maintenance
(code or profile
changes).
rgreq -o cancel
<INSTANCE_NAME_ERS>
rgreq -o move
<INSTANCE_NAME_(A)SCS>
rgreq -o stop
<INSTANCE_NAME>_
<NODENAME_PRIMARY>
rgreq -o cancel
<INSTANCE_NAME>_
<NODENAME_PRIMARY>
Expected result
ERS groups start on node1.
(A)SCS group stops on

node2 and restarts on
node1.
ERS on node1 stops after
some seconds and is
restarted on node2.
DVEBMGS/J groups stop.
DVEBMGS/J groups
restart on node1.
Table 12: Unplanned outages
Scenario
Simulation action/command
Expected result
Precondition:
ROUTER, WEBDISP, (A)SCS and DVEBMGS/J groups online on node1
ERS and D groups online on node2
To simulate a software failure create a script using the name "killscript". Add the following
content:
kill $1 `ps -ef | grep $2 | grep -v grep | awk {print $2}`
Failure of the
(A)SCS Enqueue
Server
node1:
Failure of the
Enqueue
Replication Server
Failure of the
Message Server
node1:
killscript -9
en.sap<SAPSID>_<INSTANCE_NAME_(A)SC
S>
killscript -9
er.sap<SAPSID>_<INSTANCE_NAME_ERS>
node2:
killscript -9
ms.sap<SAPSID>_<INSTANCE_NAME_(A)SC
S>
- 70 -
(A)SCS group stops and

restarts on node2.
ERS ends after some
seconds.
ERS group stops and restarts
on node1.
ERS group stops and restarts
on node1.
(A)SCS MS restarts on
node2 if restart is configured
in MS profile.
(A)SCS MS restarts on
node1 if restart is not
configured in MS profile.
Scenario
Failure of an
(A)SCS application
server
Simulation action/command
node1:
ASCS:
killscript -9
dw.sap<SAPSID>_DVEBMGS<ID>
Expected result
DVEBMGS/J application
servers restart on node1.
SCS:
killscript -2 jc.sap<SAPSID>_J<ID>
Failure of the node

where ES is running
(A)SCS groups are started on

node1.
ERS on node1 stops after
some seconds and is restarted
on node2 as soon as node2 is
available in the cluster again.
node2:
reboot
Checklist for SAP HA solution

The following Table 13 on page 71 lists all steps that are required to implement the
SAP HA solution. You can print out the table below and check the steps which you
have already finished in the column Done.
Table 13: SAP HA solution checklist
#
1.1
Tasks
Configure automounter for NFS
SAP data directory.
Reference
NFS HA installation setup on page 15
1.2
Setup IP configuration and

virtual hostnames.
1.3
Set virtual hostnames manually

(= IP-Alias Addresses).
Prerequisites on page 22 in Installing a

new ASCS or SCS HA SAP system on page
21
Installing a new ASCS or SCS HA SAP
system on page 21
2.1
Install SAP ASCS using virtual

hostname.
Install SAP Java SCS using
virtual hostname.
Install SAP Enqueue
Replication Server using virtual
hostname.
Install SAP database instance
using virtual hostname.
2.2
2.3
2.4
2.5
Install SAP Primary Application

Server.
2.6
Install SAP Additional

Application Servers.
Initial installation on primary node on

page 23 in Installing a new ASCS or SCS
HA SAP system on page 21

Initial installation on failover node on
- 71 -
Done
#
2.7
Tasks
Install SAP Web Dispatcher
(optional)
2.8
2.9
2.10
Verify SAP installation.

Stop SAP.
2.11
Unmount shared SAP file

systems manually.
3.1
Install System Automation for

Multiplatforms 3.next or later.
Create and setup a System
Automation for Multiplatforms
domain.
Activate the System Automation
for Multiplatforms domain.
3.2
3.3
3.4
3.5
3.6
3.7
4.1
4.2
Remove IP addresses manually.
Create network tie breaker.

Granting System Automation
for Multiplatforms access.
Enabling syslog daemon.
Activate SAP policy feature
license.
Reference
Verifying the initial installation on page 24

in Installing a new ASCS or SCS HA SAP
system on page 21
Chapter 1, Installing on UNIX and Linux,
on page nnn
Setting up the domain on page 28
Setting up the domain on page 28

Setting up a tie breaker on page 29
Granting System Automation for
Multiplatforms access for the <sapsid>adm
on page 28
Enabling syslog daemon on page 29
Installing the SAP HA policy feature on
page 29
Configure database HA policies. Database HA installation setup on page 14

Provide the policy parameters.
4.3
Configure SAP policies.
4.4
4.5
Start SAP HA.

Verify the SAP HA solution.
Policy parameters on page 44

Using the wizard to configure and activate
the SAP HA solution on page 66
Starting and stopping SAP HA on page 67
Verifying the SAP HA solution on page 67
- 72 -
Done

Sap Ha Pi

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sap Ha Pi

Caricato da

Copyright:

Formati disponibili

Disclaimer

Change SAP profile parameters.....................................................................65

Chapter 19. SAP High Availability Policy

Single Point of Failure (SPOF) on page 6

Example of a two-node setup on page 7

SAP HA setup options on page 8

Database HA installation setup on page 14

NFS HA installation setup on page 15

High availability impact on page 16

Single Point of Failure (SPOF)

Figure 1: Components of a distributed SAP system

SAP Central Services for ABAP instances.

SAP Central Services for Java instances.

SAP Central Services for ABAP or Java instances.

In a standard non-distributed SAP system all the main instances

Additional Application Server node

Example of a two-node setup

Figure 2: Example of a two-node setup

SAP HA setup options

Java SCS HA installation

Select the HA installation which matches your SAP installation.

Figure 3: ASCS HA setup

Web Dispatcher and SAProuter node (optional)

ABAP independent resources

Java SCS HA setup

Figure 4: Java SCS HA setup

Java SCS HA setup

Web Dispatcher and SAProuter node (optional)

Location of SAP instance directories

Database HA installation setup

High availability for DB2 and other databases

SAP NetWeaver 7.0 (2004s) Installation (2 -Installation -SAP NetWeaver

SAP NetWeaver PI 7.1 Installation (2 -Installation -SAP NetWeaver Systems)

SAP NetWeaver 7.3 Installation (2 -Installation -SAP NetWeaver Systems)

SAP NetWeaver 7.4 Installation (2 -Installation -SAP NetWeaver Systems)

High availability with other databases

NFS HA installation setup

/sapmnt/<SID>: Required to share binaries and configuration data for the

/usr/sap/trans: Has to be shared in a logical transport landscape so that

systems can pick them up from this location.

High availability impact

SA: actions taken automatically and instantaneously by System Automation

User: actions taken by the user

Table 3: Fully implemented high availability solution for SAP

Refer to Interactions between

User sessions (via

SA: Restart or Failover

Failing resource Impact

Interactions between Enqueue Server and Enqueue Replication Server

Figure 5: Initial startup of (A)SCS

Figure 6: Failure of (A)SCS and recovery of the enqueue table

Figure 7: Movement of the Enqueue Replication Server

Planning the SAP HA solution

Setup your NFS HA server. For more information, refer to NFS HA

Setup your database HA server. For more information, refer to Database HA

Installing a new ASCS or SCS HA SAP system

The installation is divided into three parts:

Create an separate directory for every installation task to store installation

Ensure to configure the automounter on all nodes to connect to the NFS

Temporarily define and activate all required virtual IP addresses on the

completed. Incorrect behaviour of the SAP HA solution occurs if you leave

3. Enqueue Replication Server instances (ERS) for ASCS or SCS

5. Primary Application Server instance