sap web application server in switchover environments

Technology Handbook:

High Availability

SAP Web Application Server in Switchover Environments

Release 6.40

February 2006

© Copyright 2004 SAP AG. All rights reserved.. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the

trademarks of their respective companies. Datacontained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver “How-to” Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent. Documentation in the SAP Service Marketplace

You can find this documentation at the following address: http://service.sap.com/ha

SAP AG Neurottstraße 16 69190 Walldorf Germany T +49/18 05/34 34 24 F +49/18 05/34 34 20 www.sap.com

Typographic Conventions

Type Style Represents

Example Text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.

Cross-references to other documentation

Example text Emphasized words or phrases in body text, titles of graphics and tables

EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, source code as well as names of installation, upgrade and database tools.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or the Enter key.

Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax


February 2006 4

Contents 1 About This Documentation ................................................................................ 6

1.1 Main Topics .................................................................................................................... 7

1.2 Target Groups ................................................................................................................ 8

1.3 Other Relevant Documentation...................................................................................... 8

1.4 Accessing the SAP Library ............................................................................................ 9

1.5 Naming Conventions...................................................................................................... 9

2 Architecture and Concepts .............................................................................. 11

2.1 SAP Web Application Server Architecture – Overview ................................................11

2.2 SAP Web AS ABAP........................................................................................................12

2.3 SAP Web AS Java..........................................................................................................15

2.4 SAP Web Dispatcher .....................................................................................................17

3 SAP Web AS ABAP .......................................................................................... 19

3.1 Protecting System-Critical SAP Web AS Components.................................................19

3.2 Switchover Scenarios ...................................................................................................23

3.3 Service Configuration for Increased Failure Resilience...............................................29

4 SAP Web AS Java ............................................................................................ 44

4.1 Protecting System-Critical Components ......................................................................44

4.2 Switchover Scenarios ...................................................................................................46

4.3 Service Configuration for Increased Failure Resilience...............................................51

5 HA Considerations for Integration Scenarios................................................. 56

5.1 Integrated Scenario .......................................................................................................56

5.2 Separate Systems .........................................................................................................58

6 Installing SAP Web AS in Switchover Environments ..................................... 61

6.1 Installing SAP Web AS Switchover Units .....................................................................61

6.2 SAP Web AS File Systems and NFS .............................................................................66

6.3 SAP Web AS License ....................................................................................................71

6.4 Additional Tasks for SAP Web AS ABAP......................................................................73

7 Switchover System Configuration................................................................... 74

7.1 Network Configuration for SAP Web AS Switchover....................................................74

7.2 Network Topologies and Virtual Network Identities .....................................................77

8 Control Scripts for SAP Web AS Switchover .................................................. 86

8.1 Tools for System Health Checks...................................................................................86


February 2006 5

8.2 Switchover Control Scripts ...........................................................................................92

9 Using Standalone Enqueue Server with Replication Server .......................... 96

9.1 Concept .........................................................................................................................96

9.2 Limitations ....................................................................................................................98

9.3 New Central Instance Concept (ABAP) .........................................................................98

9.4 Cluster Integration ........................................................................................................99

9.5 Relevant SAP Notes ....................................................................................................103

10 Appendix A: Preparations for SAP Web AS ABAP Compliance Tests....... 104

10.1 Requirements for the Test Environment...................................................................104

10.2 Preparing the Tests ...................................................................................................105

11 Appendix B: SAP Web AS ABAP Compliance Tests................................... 114

11.1 Overall Test Procedure .............................................................................................115

11.2 SAP Web AS Functionality Tests ..............................................................................115

12 Appendix C: Preparations for SAP Web AS Java Compliance Tests......... 137

12.1 Setting Up SAP Web AS Java for RFC Communication............................................137

13 Appendix D: SAP Web AS Java Compliance Tests..................................... 138

13.1 Overall Test Procedure .............................................................................................138

13.2 SAP Web AS Java Functionality Tests .....................................................................139


February 2006 6

1 About This Documentation Switchover is a standard technique to increase the availability of critical services for the SAP Web Application Server (SAP Web AS). It has been developed to minimize system downtime when critical system services fail due to hardware problems. When a host running a critical service stops functioning, a switchover transfers the service to another machine, so enabling users to continue work after a short interruption.

This documentation explains SAP’s switchover concept for the SAP Web AS. It describes system configurations where switchover strategies can be effectively implemented and gives detailed technical information on how to integrate these in a SAP Web AS. The appendices describe how to prepare and execute a series of tests. These have been designed to check the setup of switchover systems and to determine whether switchover products fully support SAP Web AS functions.

The documentation covers SAP Web Application Server Release 6.40 SP 16 and later.

Earlier Releases are described in previous versions of this document:

• SAP R/3: SAP R/3 in Switchover Environments

• SAP Web AS: SAP Web Application Server in Switchover Environments

Contents 1.1 Main Topics .................................................................................................................... 7

1.2 Target Groups ................................................................................................................ 8

1.3 Other Relevant Documentation...................................................................................... 8

1.4 Accessing the SAP Library ............................................................................................ 9

1.5 Naming Conventions...................................................................................................... 9 1.5.1 Terms .................................................................................................................................................. 9 1.5.2 Name Variables ................................................................................................................................. 10

About This Documentation

February 2006 7

1.1 Main Topics This documentation focuses on the following main topics:

For SAP systems running on MS Windows, SAP directly supports Microsoft Cluster Service (MSCS). For more information, see the SAP notes 106275 and 437406 and the accompanying installation guides (SAP Notes 728879 and 676073).

Main Topic Contents

Architecture and Concepts

Chapter 2 gives a general overview of architectural changes with SAP Web AS 6.40, and describes critical SAP Web AS components.

Addressing in Switchover Environments

Chapter 3 explains concepts required to understand and apply switchover strategies. We discuss addressing techniques, naming conventions, and introduce identity and virtual IP address takeover.

SAP Web AS ABAP Chapter 4 focuses on the system-wide single points of failure in the Web AS ABAP and looks at the consequences of failure. We explain different switchover strategies and define SAP Web AS units that can be transferred to other hosts when machines fail. In addition, we introduce standard scenarios that demonstrate successfully functioning SAP Web AS switchover environments.

SAP Web AS Java In chapter 5 we do the same for the SAP Web AS Java.

High Availability Considerations for Integrated Scenarios

Chapter 6 discusses different integration scenarios for the ABAP and Java stacks of the SAP Web AS with their high availability features.

Installation in Switchover Environments

Chapter 7 considers the installation of SAP Web AS in switchover environments including additional adjustments compared to the standard installation.

Switchover System Configuration

Chapter 8 gives an overview of the configuration of particular system functions for the usage in switchover environments (e.g. addressing, DB reconnect).

Control Scripts Chapter 9 describes tools for system health checks and their usage within switchover control scripts.

Protection of the Enqueue Service

Chapter 10 describes the functionality of the standalone enqueue service and the protection with the replication server.

SAP Web AS Compliance Tests

Appendix A, B, C, and D describe a series of SAP Web AS compliance tests to check essential system functions before and after a switchover. The tests are intended as a checklist for vendors of switchover products who want to run their software in the SAP Web AS environment. They are also useful for customers who need to check whether they have set up their local switchover system correctly.

Appendix A and C give instructions on how to prepare the system for the tests. Appendix B and D give step-by-step instructions on how to run the tests. Appendix A and B deal with the Web AS ABAP, appendix C and D with the Web AS Java.


February 2006 8

1.2 Target Groups Read this documentation if you want to implement switchover software in an SAP Web AS environment and need in-depth technical knowledge. It is also useful if you want to understand switchover strategies and the technical issues involved.

The documentation addresses the following groups:

• Switchover software vendors who want to test their products for compliance with the SAP Web AS

• Customer system administrators

• R/3 Basis consultants

1.3 Other Relevant Documentation We strongly recommend you to also read the documentation SAP High Availability . See help.sap.com/NW04: SAP NetWeaver 2004 English SAP Library SAP NetWeaver Solution Life Cycle Management SAP High Availability for a general discussion of high availability with the SAP Web AS. It is part of the standard SAP documentation package delivered together with the SAP Web AS. It deals comprehensively with safeguarding SAP Web AS system operation. You can also find it in the SAP Service Marketplace at the Internet address:

service.sap.com/ha Media Center

For information on specific switchover products, contact your hardware and switchover software vendor. If you have any questions regarding the integration of SAP Web AS with a specific switchover product, contact the Competence Centers of SAP’s hardware partners in Walldorf, Germany.

When you read this documentation, you might find it helpful to refer to the following SAP Notes that provide very detailed information on a number of topics relevant to switchover systems:

Relevant SAP Notes

Note number Topic

14838 Saplicense

41678 DB reconnect, additional information

20624 saposcol on DB host machine

19466 General info on R/3 patches

39412 Work process configuration

7209 Update configuration

524816 Standalone enqueue server

597024 Enqueue log, sequence of operations not guaranteed

569996 High availability and automation solution for DB2 on z/OS

636938 Description of the test program msprot

497427 32-bit-comaptible UNIX shared memory parameters

529088 Correcting the SAP J2EE Engine

773830 FQHN determination in ICM

757692 Changing the hostname for J2EE Engine 6.40 installation

609603 Problems with Multiple NICs and SAP J2EE Engine

803018 Central note on high availability

http://service.sap.com/ha


February 2006 9

You can access the notes in the SAP Service Marketplace at the Internet address: service.sap.com/notes

1.4 Accessing the SAP Library For more information on the SAP Web Application Server, access the SAP Library from any of the following:

• An SAP system if you have installed the documentation:

i. Choose Help → SAP Library

ii. In the browser, choose SAP NetWeaver → Application Platform (SAP Web Application Server).

... he browser starts.

• The SAP Help Portal at help.sap.com/nw04: ...

i. Select the required language.

ii. Choose SAP NetWeaver → Application Platform (SAP Web Application Server).

• The help files on the online documentation CDs

If you want to view the help files in HTML-Help format from the online documentation CDs, you need a PC running Microsoft Windows to install the HTMLHelp Viewer.

1.5 Naming Conventions

1.5.1 Terms We use the following terms to refer to components of the SAP Web AS system configuration:

Term Explanation

SAP Web AS The whole system consisting of one or more SAP Web AS instances and the underlying database management system (DBMS) seen as a single entity. Often SAP system is used as a synonym.

Database system (DB, DBMS)

Database software or database management system that supports the SAP Web AS

ABAP Central instance (CI)

SAP Web AS instance without a DBMS, but including the enqueue work process. Normally, on this machine the message server is also running. In addition, the CI normally contains additional work processes (dialog, update, batch, spool) and services such as gateway or sapcomm. A CI can work as a standalone SAP Web AS unit, but also requires a database.

When using the SAP Web AS with an integrated installation, the CI contains also the Java CI.

Java Central Instance (Java CI)

SAP Web AS instance without a DBMS, but including a Java dispatcher, Java servers, and the Software Delivery Manager (SDM).

Normally, on this machine the SCS (see below) is also running.

SAP Central Services (SCS)

SAP Web AS instance, containing the enqueue and message service for the J2EE Engine.

Central system Full SAP Web AS instance including DBMS. A central system is a standalone SAP Web AS unit.


February 2006 10

Dialog instance

SAP Web AS instance, without a DBMS, consisting of a dispatcher process and several kinds of work processes (dialog, update, batch, spool) and additional services such as gateway or sapcomm. A dialog instance does not contain the central, system-critical enqueue and message service components.

SAP Web AS instance

General expression for a single SAP Web AS client-server unit that runs on a specified host machine. An instance can be a central system or a dialog instance application server. It is started as a unit that is configured in a common instance profile.

The definition of an ABAP central instance (CI) used in this documentation is restricted and might differ from that used in other SAP documentation. We use it to mean that only the enqueue and message service have to run on the CI instance. Therefore, an AS instance becomes a CI simply by the addition of the enqueue and message services.

Apart from the CI there might also be a Java CI, which is a Web AS Java instance with SDM.

1.5.2 Name Variables Important name variables that occur throughout this documentation are listed below. The brackets indicate a variable that must be replaced by a name actually used in the system.

Variable Explanation

<INSTTYPE> The instance type on the specified host machine, that is, the type of services configured on this host. For example, DVEBMGS is the default configuration consisting of dialog, update (v), enqueue, batch, message, gateway, and spool services on a full application server.

A Java instance is named with J, the Java CI with JC, the central services instance with SCS.

<NR> The application server number on the specified host machine, for example, 00. This number defines the network port on which the dispatcher is listening. It distinguishes different SAP Web AS systems on the same host machine.

<SID> 3-character SAP Web AS system identification in capital letters, for example, TST.

<sid> 3-character SAP Web AS system identification in lowercase letters, for example, tst.


February 2006 11

2 Architecture and Concepts This chapter describes:

• Architecture of the SAP Web Application Server (SAP Web AS) compared to the SAP Basis

• Standard SAP Web AS addressing based on TCP/IP

• Techniques for making addressing transparent in a switchover system

• Critical SAP Web AS components

For more information on network configuration and addressing in switchover environments, see Switchover System Configuration, [page 74].

Contents 2.1 SAP Web Application Server Architecture – Overview ................................................11

2.2 SAP Web AS ABAP........................................................................................................12 2.2.1 Architecture Overview ...................................................................................................................... 12 2.2.2 Internet Communication Manager .................................................................................................... 13 2.2.3 HTTP Load Distribution Using Message Server ............................................................................... 13 2.2.4 System-Critical SAP Web AS ABAP Components............................................................................ 14

2.3 SAP Web AS Java..........................................................................................................15 2.3.1 Architecture Overview ...................................................................................................................... 15 2.3.2 System-Critical SAP Web AS Java Components.............................................................................. 16

2.4 SAP Web Dispatcher .....................................................................................................17

2.1 SAP Web Application Server Architecture – Overview SAP Web AS is a further development of the SAP application server technology. We have implemented new technologies based on the highly scalable SAP application server infrastructure for directly processing HTTP requests or other protocols coming from the Internet (that is, from a browser) and for sending HTTP requests as HTTP client requests to the Internet.

The following graphic compares the architecture of the SAP Web AS with the traditional SAP architecture:


February 2006 12

RDBMS

Server

Dispatcher

Gat

eway

Wor

kPr

oces

s

Wor

kPr

oces

s

Wor

kPr

oces

sMessageServer

to o

ther

inst

ance

s or

SAP

syst

ems

RDBMS

Server

Dispatcher

Gat

eway

Wor

kPr

oces

s

Wor

kPr

oces

s

Wor

kPr

oces

s

MessageService

to o

ther

inst

ance

s or

SAP

syst

ems IC

M

Internet

GUIGUI GUI

Browser

Traditional SAPArchitecture

SAP Web AS

Java Dispatcher

Java

Serv

erPr

oces

s

SAP JCo

EnqueueServer

EnqueueService

MessageService

EnqueueService

Java

Serv

erPr

oces

s

Java

Serv

erPr

oces

s

In the following sections we consider the high availability features of the new components of the SAP Web AS.

2.2 SAP Web AS ABAP

2.2.1 Architecture Overview The SAP Web AS contains the proven, scalable, and reliable ABAP technology, developed for SAP Basis.

A SAP Web AS system consists of one or more instances running on one or more application servers. Each instance can run on a separate server, or several instances can run on one server. An SAP instance can provide several types of services running on work processes: dialog, batch, update, and spool can run on all instances. Beside these standard services, there are two services that are unique to an entire SAP system: message service (not a work process but an own executable) and enqueue service. The enqueue service is a critical component of an SAP system. It maintains locks on objects within SAP transactions. These locks control concurrent accesses to SAP objects to ensure data consistency.

These services are potential single points of failure and have to be protected. A SAP Web AS instance with these two services is called a central instance.

To enhance this technology, the SAP kernel now has a new process, the Internet Communication Manager (ICM). The ICM uses threads to communicate on the Internet as a server or as a client. If the incoming HTTP request is to be processed by a worker thread, the data exchange is conducted using memory pipes, which are located in shared memory.


February 2006 13

2.2.2 Internet Communication Manager The Internet Communication Manager (ICM) is implemented as an independent process started and monitored by the dispatcher.

Its task is to make sure that the SAP system can communicate with the outside world using the protocols HTTP, HTTPS, and SMTP. In the server role, it can process requests from the Internet that have URLs with the server/port combination that the ICM responds to. Independently of the URL, the ICM then calls the corresponding local handlers.

The ICM process uses threads to parallelize the load.

ICM Plug-Ins

The ICM contains plug-ins for the protocol-dependent tasks. The Internet protocols HTTP and SMTP each have a plug-in, which perform the following tasks:

• All protocol-specific tasks

• Input and output data handling, data manipulation

• Local handling in the ICM or forwarding to the work process

ICM Server Cache

The ICM Server Cache saves HTTP objects before they are sent to the client.

The HTTP request handler uses the ICM Server Cache when, for example, response pages need to be re-used, such as the entry page of an online shop application. The first time, the request is processed in the backend. The response is stored by the ICM server cache before it is sent to the client. When the page is next called, the application gets the page directly from the ICM and sends it to the client (provided that the expiry period has not finished), and the work process does not have to be opened. This results in a considerable improvement in performance.

For more information on the ICM refer to the online documentation of the SAP Web AS:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) Architecture of the SAP Web AS Internet Communication Manager (ICM)

2.2.3 HTTP Load Distribution Using Message Server A possible solution to distribute HTTP requests among the application servers is using the message server. This solution is possible – however, SAP recommends you to use the Web Dispatcher. For more information, see SAP Web Dispatcher [page 17].

Every application server participating in load sharing tells the message server how many work processes it can support and whether it accepts HTTPS connections. At the start of a connection, an Internet client first connects to a message server, which must also be HTTP-compatible. The message server tells the client via a redirect which application server to connect to. Obviously, HTTPS requests are only sent to HTTPS-compatible application servers.


February 2006 14

DB

RDBMS

CI

AI

AI

AI

vname_ci_f

name_e1_f

name_e2_f

name_e2_f

1. request: http://vname_ci_f/appl

2. redirect to: http://name_e2_f/appl

3. request to:http://name_e2_f/appl

2.2.4 System-Critical SAP Web AS ABAP Components

SAP Web Application Server Services and Single Points of Failure

SAP Web AS Component or Service

Number of Configurable Units

System-Wide SPOF

See Page

DBMS 1 per SAP Web AS Yes 22

Enqueue service 1 per SAP Web AS Yes 21

Message service 1 per SAP Web AS Yes –

Dialog service 1...n per instance

Update service 0...n per instance 37

Batch service 0...n per instance 38

Spool service 0…n per instance 39

Gateway service 1 per instance 42

sapcomm 0 or 1 per instance 41

saprouter (WAN access) 0...n per SAP Web AS 41

NFS service 1 per SAP Web AS Yes 20

ICM 1 per instance 13

SAP Web dispatcher 0 or 1; 0 or n per SAP Web AS (*)

Yes (if used) 17


February 2006 15

(*) It is possible to run more than one SAP Web dispatcher with one SAP system (for example, one SAP Web dispatcher for a particular URL). When using SSL termination within the SAP Web dispatchers, they can even serve the same URL (in this case they need a load balancing service for themselves). However, when you use the SAP Web dispatcher with SSL and you let the application server terminate the SSL session, the SAP Web dispatcher is unique for the system and has to be protected.

The second and third columns in the above graphic show that SAP Web AS services can be divided into two groups, depending on their importance for system availability:

• Centralized services that are system-wide SPOFs for SAP Web AS

These only exist once in a SAP Web Application Server, so no redundancy can be built in. They expose the SAP Web Application Server to the threat of a single, localized hardware failure, for example, enqueue host crash. Centralized services must be protected by switchover software.

• Distributable services that are not SPOFs for SAP Web AS

You can configure these services redundantly so that they exist more than once in the SAP Web AS. They are essential to the functionality of the SAP Web AS and can, but need not be, system-wide SPOFs. System-wide failure resilience can be achieved by replicating these on several application servers.

For more information, see the documentation SAP High Availability SAP High Availability in the SAP Service Marketplace at the Internet address service.sap.com/ha.

Since this documentation is service-oriented, we use the distinction between centralized and distributable systems throughout.

Most of this documentation discusses how to protect system-wide SPOFs with switchover software.

After describing how to set up a switchover environment to protect the system-wide SPOFs, we explain how you can increase the resilience of SAP Web AS services by appropriately configuring the system. This is not only relevant for switchover environments but also for all distributed SAP Web AS systems.

2.3 SAP Web AS Java

2.3.1 Architecture Overview SAP Web AS Java is a complete implementation of the Java™ 2 Enterprise Edition standard. You can download the J2EE specification and its sub-standards from the Internet address java.sun.com.

The standard was developed to define an environment where enterprise applications written in Java can run more easily and to provide the infrastructure required by such applications. It includes services as:

• Java Server Pages

• Java Servlets

• Enterprise Java Beans

• Java™ Message Service

• Java Mail™


February 2006 16

Web AS Java Instances

Java ServerProcess

Java ServerProcess

Java

Dis

patc

her

MessageService

EnqueueService

Central Services

RDBMS

Web AS Java Central Instance

Java ServerProcess

Java ServerProcess

Java

Dis

patc

her

SDM IGS

IGS

SAP Web AS Java 6.40 Cluster

The SAP Web AS 6.40 offers a new architecture for the Java cluster. The new architectures includes a central database to store configuration information and application data and central services (message service, enqueue services) from the ABAP stack. The Software Delivery Manager SDM is the tool to deliver new software components to the Web AS Java.

With the new cluster architecture, the SAP Web AS Java reaches a new level of scalability. With release 6.40, the SAP Web AS Java has a new communication schema within the cluster. With release 6.20, there were no central services and each cluster element communicated with all other cluster elements. This was a limiting factor for scalability and the main reason for changing the architecture.

However, there are now potential SPOFs that have to be protected with proper measures.

Dispatcher

Server ServerServer

Database EnqueueServer

MessageServer

Central Servicespotential SPOFs

2.3.2 System-Critical SAP Web AS Java Components

SAP Web AS Java Services and Single Points of Failure

SAP Web AS Java Component or Service

Number of Configurable Units

System-Wide SPOF

See Page

DBMS 1 per SAP Web AS Java Yes 45


February 2006 17

Enqueue service 1 per SAP Web AS Java (part of SCS instance)

Yes 45

Message service 1 per SAP Web AS Java (part of SCS instance)

Yes 45

SDM 1 per SAP Web AS Java (part of CI)

Yes (*) 51

Java instance 1..n per SAP Web AS Java No

Java dispatcher 1 per Java instance No

Java server process 1..m per Java instance No

NFS service 1 per SAP Web AS Yes 20

(*) The Software Deployment Manager (SDM) is the component to deliver applications to the SAP Web AS Java. The SDM is located on the central instance of the SAP Web AS Java. If it is not available, no new software components can be deployed to the SAP Web AS Java (this might not be an issue in production environments). In this document, we do not describe high availability measures for the SDM. If required, you should take precautions to protect the Java CI similar to the (ABAP) CI. For more information, see Software Delivery Manager [page 51].

2.4 SAP Web Dispatcher The SAP Web dispatcher is used as a "software Web switch" between the Internet and your SAP system, which consists of one or more SAP Web AS instances. Therefore, you have only one point of access for HTTP(S) requests in your system. Furthermore, the SAP Web dispatcher balances the load, so that the request is always sent to the server with the greatest capacity. We recommend using the SAP Web dispatcher when you use a SAP Web AS with several instances for web applications.

The SAP Web dispatcher is a program that you can run on the machine that is connected directly to the Internet. It is very easy to configure. The profile file of the SAP Web dispatcher only needs to know the port on which to accept HTTP(S) requests, where it can find the SAP message server, and on which port it accepts these HTTP requests.

If you want to call the Web application externally – for example, using the URL www.shop.acme.com – this host name must be mapped internally to the SAP Web dispatcher. This then forwards the HTTP(S) request to a suitable SAP Web AS instance.

The SAP Web dispatcher is located between the Web client (that is, browser) and your SAP system that is running the Web application.

It forwards the incoming requests (HTTP, HTTPS) to the SAP Web AS instances. The number of requests that are sent to an instance depends on its capacity, which depends on the number of dialog work processes that are configured. If the application is “stateful,” the SAP Web dispatcher makes sure that, with the next request, the user is forwarded to the server that is processing his or her application. To do this, it uses the session cookie with HTTP connections and the client IP address with HTTPS connections using end-to-end SSL.

The SAP Web dispatcher also decides whether to forward the incoming request to an ABAP or Java server.

Unlike HTTP load balancing using the message server, redirects are not executed when the SAP Web dispatcher is used. This avoids the related disadvantages, for example, that several IP addresses must be known, bookmarking is not possible, and authentication is required after changing the application server.


February 2006 18

Internet DMZ Intranet

RDBMS

SAP Web Application Server

CentralInstance

ApplicationServers

DB Server

Fire

wal

l

Fire

wal

l

WebDispatcher

HTTPS(end-to-end SSL)

HTTPS(Web Dispatcher can decrypt SSL) HTTP/HTTPS

For more information on the SAP Web dispatcher refer to the online documentation of the SAP Web AS:

SAP Library SAP NetWeaver Solution Life Cycle Management System Management SAP Web Dispatcher

The Web Dispatcher can be used for the following scenarios:

ABAP-only scenario

Java-only scenario

Integrated scenario (Java+ABAP): see next section

SAP Web AS ABAP

February 2006 19

3 SAP Web AS ABAP

Contents 3.1 Protecting System-Critical SAP Web AS Components.................................................19

3.1.1 Switchover Units............................................................................................................................... 20 3.1.2 Failure and Switchover of the CI Service (Enqueue Host Failure)................................................... 21 3.1.3 Failure and Switchover of the DB Service........................................................................................ 22

3.2 Switchover Scenarios ...................................................................................................23 3.2.1 Definition .......................................................................................................................................... 24 3.2.2 Scope of Switchover Scenarios ....................................................................................................... 24 3.2.3 Hardware Requirements ................................................................................................................... 25 3.2.4 Restrictions for Identity Takeover Scenario .................................................................................... 25 3.2.5 Additional Information...................................................................................................................... 26

3.3 Service Configuration for Increased Failure Resilience...............................................29 3.3.1 Dialog Service and Logon with SAP GUI.......................................................................................... 29 3.3.2 Message Server Based Logon and Load Balancing (Redirection)................................................... 32 3.3.3 Logon and Load Balancing Using the SAP Web Dispatcher ........................................................... 32 3.3.4 Internet Communication Manager .................................................................................................... 36 3.3.5 Update Service.................................................................................................................................. 37 3.3.6 Batch Service.................................................................................................................................... 38 3.3.7 Spool Service.................................................................................................................................... 39 3.3.8 Further ABAP Related Services ....................................................................................................... 40 3.3.9 Problems and Solutions ................................................................................................................... 42

3.1 Protecting System-Critical SAP Web AS Components This section discusses how you can use switchover strategies to protect services that are of critical importance for the availability of an SAP system. Services that are vital for the operation of an SAP Web AS system are:

• Enqueue service

• Message service

• DBMS

• Network File System (NFS) Service

These are also known as system-wide, single points of failure (SPOFs) because they cannot be configured redundantly. If a host running one of these services crashes, the service can be transferred to another host within the cluster using switchover software. This section explains how to do this using switchover strategies and illustrates this with a set of standard switchover scenarios.

The protection of other SAP Web AS services that are not SPOFs is described in Service Configuration for Increased Failure Resilience [Page 29].

SAP Web AS ABAP

February 2006 20

3.1.1 Switchover Units SAP recommends grouping the system-critical SPOFs in the SAP Web AS into the following switchover units:

• CI – central SAP Web AS instance with enqueue and message service

• DB – database management system

• NFS – network file system

We recommend placing both the enqueue and message server on the CI because the enqueue service is always accessed via the message service for inter-process communication. Distributing the message and enqueue services across different host machines normally lowers performance because of the network overhead.

We consider DB and NFS services to be separate service packages. Depending on how many host machines are available in the switchover cluster, there are several ways to distribute them. In this chapter, we include NFS in the switchover scheme, whereas in other chapters we assume that it is part of the operating system and do not deal with it explicitly. For more information, contact your hardware and switchover product vendors.

The table below shows the different ways you can distribute services across two or three hosts in a switchover cluster:

Distribution of SAP Web AS system-Critical Services

Cluster Node 1 Cluster Node 2 Cluster Node 3 Use

DB/CI/NFS Central system

DB CI/NFS Mutual takeover, NFS on CI node

DB/NFS CI Mutual takeover, NFS on DB node

DB CI NFS Separation of all services, NFS on dedicated server

When choosing an appropriate configuration for a switchover cluster, consider the points described below.

Separation of the CI and DB

It is often better to separate the DB and CI, locating them on two different host machines of the switchover cluster. Separating the DB service from the CI is a general option that is available with SAP’s three-tiered architecture. We recommend it when the SAP Web AS runs in a multi-host environment with a heavy database workload. The dedicated DB host is freed of both the CI workload and the dialog workload of additional application servers.

If the DB host does not include the CI or another AS instance, you need to take special precautions if you want all available CCMS functions to work. The saposcol process must run on the DB host.

For more information, see SAP Note 20624.

NFS Service

In a SAP Web AS system, several directories have to be NFS mounted. In most cases either the database node or the central instance node act as the NFS server, but this depends on your database. For example, if you are using an Informix database, the NFS server has to be located on the DB node. In this case one NFS belongs to the Informix database.

From the perspective of SAP Web AS, NFS is considered to be part of the operating system (OS) underlying SAP Web AS. Contact your vender of OS and switchover software for help with setting up

SAP Web AS ABAP

February 2006 21

NFS correctly for your database. Although no installation guidelines are included in this documentation, you can find more information in Configuring NFS [Page 70].

Failure and Switchover of SAP Web AS Units

The most critical units of the SAP Web AS are the CI and the DB. Failure of a machine hosting one of these has a severe impact on the availability of the SAP Web AS system. The impact differs, depending on the unit that is affected:

• The most important consequence of CI host failure is the loss of the enqueue service. The locks held by the SAP Web AS system are lost and the enqueue service has to be restarted (unless using replicated Enqueue, described later in this paper). The message service is also disabled. Communication between the different application servers in the distributed system also fails or is impeded.

• Loss of the database host implies that transactions accessing the database are held up as long as the DB is unavailable. If the DB reconnect feature is enabled, work processes on another unaffected application server can reconnect to the database system that is started up after switchover.

You can find more information in the following sections.

3.1.2 Failure and Switchover of the CI Service (Enqueue Host Failure)

General Consequences of CI Host Failure

The enqueue server is a critical SAP Web AS system-wide SPOF. If the machine hosting it (that is, the CI instance) fails, all SAP-locks for transactions that have not yet been committed are lost. The SAP Web AS is designed so that locking information is maintained exclusively in the memory of the host machine running the enqueue server. This is mainly for performance reasons and is true for all current SAP Web AS Releases.

The SAP Web AS guarantees that no user can perform a transaction when the enqueue server (that is the CI in our definition of switchable units) is not available. This rule guarantees database consistency in the event of enqueue (or CI) failure.

The enqueue service needs to be restarted to continue normal work with the SAP Web AS. This means that, after the CI has been switched over to another host, it has to be restarted. However, external SAP Web AS application servers on different host machines might still be holding open uncommitted transactions. These might be holding enqueue locks that have been lost and are not visible anywhere in the entire SAP Web AS system.

If no precautions are taken, any user in the SAP Web AS system can then lock the same object and change it in the database. Obviously, this can lead to database inconsistency. Therefore, all open transactions in the entire SAP Web AS system must be aborted and rolled back before the enqueue service (the CI) is restarted.

Of course, CI failure also implies failure of the message service. As most system activities require this service, it has to be restarted to continue normal system operation. Apart from this, the impact of message service failure is less severe than that of enqueue service failure.

System Impact

As the CI includes the enqueue server, host failure and CI switchover mean that SAP locks for transactions that have not yet been committed are lost. Actions required are:

• All running transactions holding locks are aborted and users are notified by a message in the status line.

• All user input for all transactions that have not been finished with the ABAP command COMMIT WORK has to be re-entered.

In the case of a planned CI switchover, you need to inform users and give a deadline for them to commit all their transactions. After all transactions have been committed and update tasks

SAP Web AS ABAP

February 2006 22

finished, no SAP locks are held, so no locking information is lost during shutdown. Make sure that there are no update requests in status init (SM13) before stopping the CI. You do not need to restart the other application servers. Therefore, their buffers do not have to be refilled and so there is no negative impact on performance.

The SAP system can automatically handle transaction reset and the reset of SAP locks within certain limitations. Pay careful attention to the specific requirements described further below.

System Impact

CI host failure and CI switchover have the following impact on your system:

• SAP locks for transactions that have not yet been committed are lost at a system-wide level.

• Normally, only the CI needs to be restarted.

• All AS instances can stay up and running.

• Only those interactive users who are directly connected to the CI have their sessions disconnected. All other users stay logged on to their application servers.

• All user input for all transactions that have not been finished with the ABAP command COMMIT WORK needs to be re-entered.

In the case of a planned CI switchover, you need to inform users and give them a deadline to commit all their transactions.

Performance Impact

There is no reduction in performance on the application servers (AS instances) due to memory buffer rebuild. The buffer contents of all the AS instances (except the CI, of course) are preserved, and the system immediately returns to its optimal buffer hit-ratio and corresponding performance level. However, as long as the CI is not available, no update transactions can be performed.

It makes most sense to use the standalone enqueue server if your system has a high availability solution, and you want to eliminate the enqueue server as the single point of failure.

This changes the role of the CI, because the system-critical services can be concentrated on a lean instance that enables a fast restart and recovery. For more information on the enqueue server refer to the online documentation of the SAP Web AS:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) ABAP Technology Client/Server Technology The SAP Lock Concept

3.1.3 Failure and Switchover of the DB Service

General Consequences of DB Host Failure

In the event of DB host failure, the network connection of SAP work processes to the DBMS is lost. Such an error might, for example, be due to the failure of the DB host, a database shutdown, or a network failure. If a work process encounters an error in the database connection, the built-in “DB Reconnect” mechanism starts, and tries to re-establish the database connection.

DB Reconnect

The DB Reconnect feature makes sure that all work processes of all SAP Web AS instances are automatically reconnected to the DB as soon as the DB service is restarted and becomes available again. This means the work processes can transparently recover after temporary DB failure.

All local memory buffers of the host machines of the SAP Web AS instances are preserved. The SAP Web AS system performance on the machines after switchover is as optimal as before because the local memory buffers remain well tuned and buffer hit rates are correspondingly high.

SAP Web AS ABAP

February 2006 23

To the end user, the temporary DBMS failure is almost fully transparent, apart from the time taken for the DB service to be switched over and become operational again. Note that the functionality offered depends on the type of access service involved – that is, dialog, batch, or update.

Technical Details

DB Reconnect avoids a shutdown of all work processes and therefore of all SAP Web AS instances.

If pre-defined errors are returned from the database to a work process, this process is set to “reconnect” status. The transaction run by the process is terminated. However, the process itself continues to run and informs all other work processes (irrelevant of type) on the host about the DB restart. If the DB is not available, all work processes switch to this status within a short period of time.

Whenever a user request is received, a work process in this status tries to reconnect to the database system before it starts the requested transaction. If the database is accessible again, a work process in the reconnect state lets the transaction start without terminating. This is transparent to the user. If the database connection cannot be re-established, the transaction does not start and the user is informed by a popup message about the lost database connection.

For more information, see SAP Note 98051.

Requirements and Implementation

In principle, you can use DB Reconnect in all situations where the DB fails (host failure, planned shutdown, temporary interruption of the connection to the DB host). Both the CI and AS instances are configured to take advantage of the reconnect. However, if an instance is (re-)started without being able to access the database, the instance stops. There is no reconnect at startup time. The same applies to the restarted work process: if the initial connect fails, the work process is stopped and is not restarted.

3.2 Switchover Scenarios The following sections deal exclusively with host failure and switchover of the SAP Web AS DB and CI units. NFS is not included in the examples because we consider it to be part of the operating system, which is handled externally by the switchover product. For more information on NFS see Configuring NFS [Page 70].

The switchover of AS services is not included in the SAP Web AS switchover scenarios for the following reasons:

• You ought to configure services that are of critical importance to your business redundantly on several AS hosts to increase failure resilience. This makes sure that a single AS instance does not contain services that are critical system-wide SPOFs. Therefore, AS instances do not necessarily need to be part of the switchover cluster.

• If you need to centralize a particular service – that is, batch, update, spool, or gateway – on one dedicated host, which in effect introduces another system-wide SPOF, configure it as part of the CI on the switchover cluster. This means that the CI switchover then also applies to this service.

• You can safeguard the availability of the dialog service and the SAP GUI by appropriately configuring AS hosts and front ends.

Heterogeneous operating system environments that run several different operating systems at the server level (CI, DB, AS instances) introduce additional complexity into a switchover system.

To run the SAP Web AS in a switchover environment successfully, SAP strongly recommends that switchover actions only take place between equivalent operating

SAP Web AS ABAP

February 2006 24

systems. Switching between different operating systems is highly complex and we do not recommend it.

Assuming that the CI is running under the operating system Microsoft Windows and the DB on a UNIX platform, then the CI can only switch to another Windows machine and the DB to another UNIX machine. It is not permissible to mix these options and to cross-switch the CI to UNIX or the DB to Windows.

Here we only consider switchovers performed in a two-node cluster. This type of setup is sufficient for test purposes. Clusters including more host machines allow more complex setups for switchover. The two-node examples provided can be used as basic building blocks to construct other types of switchover setups.

3.2.1 Definition This section defines the principal hardware failure scenarios and corresponding switchover scenarios. It provides well-defined test scenarios for vendors of switchover software that need to test their products for compliance with the SAP Web AS. We describe more detailed real-life setups in Additional Information [Page 26].

Switchover Scenarios for the SAP Web AS

Scenario Normal Operation After Switchover

Switchover Cluster

External Nodes

Switchover Cluster

External Nodes

Node C1

Node C2

Node E1

Node E2

Node C1

Node C2

Node E1

Node E2

SO-1 CI DB ⎯ AS failed DB+CI ⎯ AS

SO-2 DB CI ⎯ AS failed CI+DB ⎯ AS

SO-3 CI/DB AS ⎯ AS failed CI/DB ⎯ AS

SO-4 CI AS DB AS failed CI DB AS

SO-5 DB AS CI AS failed DB CI AS

SO-6 DB Idle CI AS failed DB CI AS

3.2.2 Scope of Switchover Scenarios You might want to construct more complex setups than the ones given above to meet your specific requirements. Although such setups are not explicitly part of the test scenarios, be aware that you can put together complex setups by using these scenarios as the basic building blocks.

The scenarios listed cover all the main configurations of SAP Web AS switchover between two cluster machines, C1 and C2. Note that SAP Web AS switchover is restricted to the CI and DB instances. These are the only switchable entities of an SAP Web AS system (that is, no AS switchover, no separation of enqueue from message service, and so on).

The SAP Web AS component running on cluster node C1 (CI/DB, CI or DB alone) is switched over to another cluster node C2. Cluster node C2 might already be running a different SAP Web AS component (CI/DB, CI, DB, AS) or might be idle.

Some distributions of SAP Web AS components over the two cluster hosts C1 and C2 are not valid SAP Web AS configurations and are shown as shaded areas in the next table below. For example, the distribution C1:CI/DB and C2:CI is obviously not possible because a SAP Web AS system can only have one CI host.

The following table gives a systematic overview of all main configurations of switching over SAP Web AS units in a cluster with 2 nodes. The SAP Web AS component running on cluster host C1 during

SAP Web AS ABAP

February 2006 25

normal operation is given in the rows, the one running on cluster host C2 is given in the columns. The corresponding switchover scenarios defined in the table above are indicated here:

SAP Web AS Switchover on a Two-Node Cluster

C2

CI/DB CI DB AS idle

CI/DB SO-3 (SO-3)

CI SO-1 SO-4 (SO-4)

C1

DB SO-2 SO-5 SO-6

3.2.3 Hardware Requirements It is important to adequately equip host machines within a switchover cluster. Sufficient CPU power, RAM, I/O capacity, network capacity, and so on, must be available if a switchover occurs and the machine that is taking over another component has increased demands. This applies especially to scenarios SO-1 and SO-2, where one machine takes over the workload that was previously handled by two machines. It might also be relevant when an application server substitutes a CI or DB instance after switchover.

Generally, make sure that even in a switchover situation the hardware is adequately sized to run the increased workload. You might be able to accept some degradation in performance in an emergency. However, it is unacceptable if the system comes to a standstill because it is overloaded after switchover.

Depending on the switchover scenario chosen, the underlying hardware might require oversizing to run the switchover cluster successfully. In some cases it might be advisable to provide identical standby machines for critical server machines. These could be idle, run non-critical services, or serve as additional AS instances. For example, see the above scenarios SO-3/4/5 [Page 24].

In accordance with the scenario definitions, the following minimal hardware configuration is necessary to run and test the SAP Web AS in a switchover environment:

• A two-node switchover cluster

• One or two additional cluster-external host machines, depending on the scenario

The second, external host machine E2 is included in these scenarios for test purposes only. It has to be available for the SAP Web AS compliance test to prove that connections from an external AS instance can be handled in switchover situations. For more information, see Appendix A and B.

You can omit the E2 node from your setup if only two (SO-1, 2, 3) or three host machines (SO-4, 5) are available. You can also choose more complex setups, as long as these can be derived from the building blocks given above. The clusters can in principle also contain three, four, or more host machines.

3.2.4 Restrictions for Identity Takeover Scenario Note that the choice of scenarios for the identity takeover strategy is restricted to scenarios SO-3, SO-4, SO-5, and SO-6 only. It is obviously not possible to make the host setup of a joint DB+CI instance fully identical to either of its former components, that is, the CI or DB nodes. For virtual IP address takeover, you can equally well use any of the scenarios SO-1 through SO-6.

SAP Web AS ABAP

February 2006 26

3.2.5 Additional Information

Scenarios SO-1 and SO-2

In scenarios SO-1 and SO-2, the CI and DB instance have been separated on two clustered machines with mutual takeover of the complementary service. If the first node fails, the failing service – either DB or CI – is switched to join the complementary service (either CI or DB) on the second cluster node. Of course, you can configure SO-1 and SO-2 together in a switchover cluster so that both switchover directions are possible at any time. When a failure occurs, the switchover product decides in which direction switchover occurs – that is, CI joins DB host or DB joins CI host.

Scenarios SO-1 and SO-2 Combined in One Cluster

Cluster

CI DB AS

Cluster

CI CI+DB AS

Cluster

CI+DB DB AS

Scenario SO-3

Scenario SO-3 offers an option for central system switchover: CI and DB are both running on one host machine. The second cluster node (C2) is running an AS instance, which is shut down before the CI/DB is switched over. The switchover is initiated by the failure of node C1. Of course, it is possible to configure node C2 as an idle standby. However, most customers prefer to run an additional AS instance on the standby hardware. This is why SAP has included the latter scenario in the test scenarios.

Scenario SO-3

Cluster

CI+DB AS AS

Cluster

CI+DB CI+DB AS

SAP Web AS ABAP

February 2006 27

Scenarios SO-4 and SO-5

Scenarios SO-4 and SO-5 require a dedicated standby host for the CI or DB. They have been included for two different purposes:

• Dedicated standby nodes are necessary for a switchover in mixed operating system environments. If the DB and CI (or AS instances) are running on different operating systems, dedicated standby machines are necessary. This follows the rule that it is not permissible to cross-switch part of SAP Web AS (CI or AS) from one operating system to another.

• Standby nodes dedicated for CI and DB takeover are an option for very demanding high availability environments. Both the DB and CI have dedicated standby machines simultaneously (SO-4 and SO-5 simultaneously in a cluster of four host machines). The standby machine can also be the same for both, as in a cluster of three host machines. Both standby hosts can run additional AS instances that are shut down in the event of switchover.

In SO-4, the CI is switched to a standby machine. The standby node runs an AS instance that is shut down before the CI is switched over. This is the required test setup for the SAP Web AS compliance tests.

In SO-5, the DB is switched to a standby machine. The standby node runs an AS instance that is shut down before the DB is switched over. This is the required setup for the SAP Web AS compliance tests.

For both SO-4 and SO-5 scenarios, you can also configure node C2 as an idle standby. However, this is only possible in customer installations. Test installations for SAP Web AS compliance must run the AS instance on the standby. Most customers prefer running an additional AS instance on the standby hardware.

The following graphic shows a real-life setup for scenarios SO-4 and SO-5 combined on a 3-node switchover cluster. An additional standby machine in the cluster is running an AS instance. The AS can be shut down and take over either the CI or DB.

Scenarios SO-4 and SO-5 on a 3-Node Cluster

Cluster

CI AS ASDB

Cluster

CI CI ASDB

Cluster

CI DB ASDB

SAP Web AS ABAP

February 2006 28

The following graphic illustrates a real-life setup for scenarios SO-4 and SO-5 combined on a 4-node switchover cluster. Both CI and DB have their dedicated standby machine in the cluster. You can shut down the AS instances to take over the CI and/or DB. Both the CI and the DB host might fail simultaneously (see last row).

Scenarios SO-4 and SO-5 on a 4-Node Cluster

Cluster

CI AS ASDB AS

Cluster

CI CI ASDB AS

Cluster

CI AS DBDB AS

Cluster

CI CI DBDB AS

Scenario SO-6

Scenario SO-6 requires a dedicated standby for the DB instance. Since you are not allowed to cross-switch part of the SAP Web AS (CI or AS) from one operating system to another, you might in some cases have to have a separate DB switchover to an idle standby machine. “Idle” means that there is no component of the switchover SAP Web AS system running on the standby host. In principle, there might be a different SAP Web AS system, for example, a test SAP Web AS system on the idle host.

This scenario has been included for installations and hardware partners that need to run the DB on an operating system on which the SAP Web AS system cannot run. This is for mixed operating system environments only. Apart from the application running on the standby host C2 (“idle” in SO-6, AS in SO-5), it is identical to SO-5.

In SO-6, the DB is switched to its dedicated standby machine. All SAP Web AS instances (CI, AS) are running on another operating system external to the DB switchover cluster. The standby host C2 must be idle. It takes over the DB if host C1 fails.

As an example of employing scenario SO-6 in a heterogeneous OS environment, consider the following:

Assume that the DB is running on UNIX and that the SAP Web AS instances (CI, AS) cannot be run on the same operating system for some reason and are on Windows. The whole system is a mixed OS environment. The host machines C1 and C2 form a UNIX-based switchover cluster that is used to secure the high availability of the DB. The database system is installed on host C1. The other cluster host C2 is running idle. C2 is configured to take over the DBMS if host C1 fails. The SAP Web AS central instance CI is running independently on the external Windows host machine E1. You should

SAP Web AS ABAP

February 2006 29

consider Microsoft Cluster Service (MSCS) to protect the CI. Another AS is attached to the external Windows host E2.

Scenario SO-6 with Dedicated Standby for the DB

Cluster

DB idle ASCI

Cluster

DB DB ASCI

3.3 Service Configuration for Increased Failure Resilience Up to now, this documentation has focused on protecting system-wide single points of failure in the SAP Web AS by transferring critical services to other machines using switchover strategies. From now on we discuss how to protect other critical SAP Web AS services by configuring the system appropriately.

This chapter explains how to safeguard the following services:

• Dialog service and logon

• Update service

• Batch service

• Spool service

These services are implemented as work processes and, in principle, can be configured redundantly by adding another work process of the same type, either on the same machine or on another SAP Web AS instance. Such redundancy is as important for the high availability of an SAP Web AS system as the switchover environment itself.

For more information about configuring services, see the documentation SAP High Availability SAP High Availability [Page 8]. Also refer to SAP Note 39412 which includes general guidelines on how to configure work processes

3.3.1 Dialog Service and Logon with SAP GUI

We use SAP GUI as a synonym for SAP GUI for Windows. Note that there are additional SAP GUI products: SAP GUI for Java and SAP GUI for HTML. They use the same load-balancing mechanisms, based on logon groups and the message server. However, SAP GUI for HTML needs the Internet Transaction Server (ITS), which you must also consider for high availability.

For more Information about high availability for the SAP ITS see the following documentation in the SAP Service Marketplace:

service.sap.com/ti SAP NetWeaver SAP Internet Transaction Server- Technical Infrastructure

When a user logs on, a connection is established from the SAP GUI to a dialog instance. This is either the CI or an additional AS, which is running several dialog work processes internally. In general, the

SAP Web AS ABAP

February 2006 30

user’s SAP GUI remains connected to the same SAP Web AS instance as long as the session lasts. If the SAP Web AS dialog instance (CI or AS) fails, the user is disconnected, loses all open transactions, and has to log on manually to another SAP Web AS instance running dialog work processes.

Logon Techniques

There are the following techniques for logging on:

• Direct logon to a particular host machine and SAP Web AS instance

• Group logon to a group of machines with an available dialog service using SAP Web AS logon load balancing

A direct logon is always possible as long as the host name of the SAP Web AS instance and the number of the application server are known.

A group logon with load balancing delivers a more complex service to the user, requiring more attention to accurate network and SAP Web AS configuration. The appropriate configuration depends on the network topology – more precisely, on whether a single or two separate LANs are used for server and front-end network access. In all cases, you must make sure that the logon is transparently possible, even in situations where services are migrated.

For more information on logon load balancing in the SAP Web AS from a standard (not a switchover) viewpoint, see the SAP documentation Computing Center Management System, available in the SAP Library [Page 9].

Logging on to a Specified Host Machine

If a group logon is not performed, the user connects directly to a host running a specified SAP Web AS system, which is the standby host after a failure. To log on in this way, the user must enter the following command:

sapgui <local hostname> <NR> on Windows machines (or click icons)

Note that the <local hostname> of the standby host and the application server number <NR> must be explicitly known by users to enable them to choose the correct machine in the event of a switchover.

If the mapping of virtual host names to IP addresses is correctly configured in the network, it is also possible to connect the SAP GUI to a <virtual hostname>. This makes the logon more transparent to users in the event of a switchover. However, the LAN that serves the front-end (SAP GUI) connects must be able to access virtual host names directly or using appropriate routing entries. The network setups that we recommend for switchover environments both meet these requirements. For more information, see Single-LAN Network [page 79] and Two-LAN Network[page 82]

Users can enter the following command to log on again after switchover, if you have correctly configured virtual host names:

sapgui <virtual hostname> <NR> on Windows machines (or click icons)

Here <virtual hostname> is the host name configured for a switchable SAP Web AS instance (normally the CI) running on the switchover cluster.

Group Logon and Load Balancing in Switchover Environments

For the SAP Web AS logon process (saplogon) on front-end machines, you can define groups of SAP Web AS instances (group logon) that together provide the dialog service to users. Users do not log on to a specified machine, but log on to a group. The system connects the front-end session to the preferred machine, so enabling dialog workload balancing among the different instances.

To log on, the user selects a particular group for the desired SAP Web AS system. The front end contacts the message service of this system by looking up the message server’s location (CI) on the local front end in the SAPLOGON.INI file. The message service determines the instance (CI or AS) that the GUI connects to in order to achieve a balanced logon load. It chooses the instance from a list that contains either the SAPLOCALHOST names (if this parameter is set on the host machine) or the

SAP Web AS ABAP

February 2006 31

local host names of instances (if SAPLOCALHOST is not set on the particular host). The decision to connect to a particular instance is made by the message server based on actual response time, number of users, and a “favorite factor.”

The details of this process depend on the network topology. Therefore, proper configuration of the network and the internal address parameters of the SAP Web AS becomes a critical issue:

• For a simple network topology, where only one LAN is used for the front-end and server traffic of the SAP Web AS system, no problems result from this approach.

• If two separate LANs are used to separate the front-end from the server network traffic, you must pay careful attention to network configuration. For more information, see Virtual IP Address Takeover [page 75], which describes virtual addressing setups that ensure a transparent logon in all switchover situations.

The consequences of host failure also depend on the service that is running on the failing host:

• If the front-end GUI was connected to an AS that failed, the situation remains transparent. Either you log on directly to another specified instance or you use load balancing again. The message service running on the CI is still accessible at the same network address for the saplogon program. The user can log on to the same logon group as usual and is automatically connected to a different SAP Web AS instance by the message service, provided that there is another machine available within the group.

Therefore, AS host failure is not critical to the availability of the dialog service as a whole, as long as the CI host machine on the cluster is functioning. This is also one of the reasons why it is not essential to make AS machines part of the switchover cluster and to protect them directly with switchover software.

• Suppose the front-end GUI was connected to the CI, but the CI has failed and has been switched over to a different host machine. This implies that the message service that is handling the group logon has moved to a different host machine. A fixed addressing scheme that is not using identity takeover or virtual addressing is no longer sufficient for the front-end connects. For these cases virtual addressing is necessary and you have to set it up with special care, taking account of the specific network topology.

Load Balancing on a Single-LAN Network

You can also use virtual addressing for the front-end connections if there is one common LAN for both the following:

• Server traffic – SAP Web AS instances accessing each other, between SAP Web AS instances and the DBMS

• Front-end connections – front end to application servers or CI

Using virtual addressing for the front-end connections makes a group logon transparent in switchover situations because access to the switched CI is transparent when a virtual address is available for the CI. To enable this you simply use virtual addresses in the front-end SAPLOGON.INI file that is used to look up the location of the message service. If the CI fails, the switchover product migrates the SAP Web AS instance and the virtual IP address on the front-end LAN to another node. The user is logged off, but is able to log on again transparently by double-clicking on the same group icon.

Load Balancing on a Two-LAN Network

To configure a two-LAN network for a switchover environment, you must use the option described in Separate CI and DB Instance in a Single-LAN Network [page 79]. If the user is logged off, it is possible to log on again by double-clicking on the same group icon. Two virtual addresses are used per host, one on the server and one on the front-end LAN. Both migrate simultaneously with their dedicated SAP Web AS component (CI or DB). Logon groups use the virtual front-end address in the CI front-end file SAPLOGON.INI that is used to look up the location of the message service. The message service returns the front-end addresses (virtual for the CI, normal addresses for AS), which can be accessed directly on the front-end LAN. The path for performing the user logon is not affected by the routing that is only needed to separate the server traffic from the front-end traffic at a later stage.

SAP Web AS ABAP

February 2006 32

3.3.2 Message Server Based Logon and Load Balancing (Redirection) The SAP Web Application Server provides the possibility for a message server based on redirect of HTTP/HTTPS requests.

The approach is the same as for logon load balancing with SAPGUI: the message server redirects the first request to the application server with the least workload. Each subsequent request is handled by the same server as the first request.

Each application server taking part in the load distribution tells the message server how many work processes it provides and whether it supports HTTP/HTTPS. When started, each HTTP client connects to the message server. The message server tells the client which server it has to connect to. HTTPS requests are only redirected to an application server accepting HTTPS.

To configure the message server to accept HTTP and HTTPS requests, you have to set the following parameters:

• ms/http_port

• ms/https_port

For more information on configuring message-server based HTTP load balancing, see the documentation for the SAP Web Application Server.

To make sure that the message server can be reached after a switchover, you have to use virtual names and addresses.

Redirection has certain disadvantages that prevent it from being more extensively used in Internet scenarios:

• The client has to access the message server and the application servers directly, which is to be avoided for security reasons.

• The use of bookmarks is limited, as bookmarks always point to a particular application server.

• It is necessary to provide an extra server certificate for each server because of the different URLs.

• When a server fails there is no possibility of failover. A browser refresh is not sufficient, because the URL is no longer valid. The client has to connect to the message server again to initiate a new redirect.

However, the redirection approach does not need further precautions for stateful and HTTPS sessions because the session always remains on the same host.

3.3.3 Logon and Load Balancing Using the SAP Web Dispatcher

For more information on the SAP Web Dispatcher, see the documentation [Page 9]:

SAP Library SAP NetWeaver Solution Life Cycle Management System Management SAP Web Dispatcher

With release 6.20, SAP introduced a new infrastructure component of the SAP Web AS, the SAP Web dispatcher. The SAP Web dispatcher – like other 3rd party web switches – receives HTTP/HTTPS requests and directs them to a number of servers that remain transparent to the client.

The benefit of the SAP Web dispatcher is the automatic configuration using message server information, which means you do not need to perform comprehensive manual configuration.

For more information on configuration, refer to the documentation for the SAP Web Application Server.

You need to consider the following topics:

• Load-balancing mechanism

• Session persistence for stateful sessions

SAP Web AS ABAP

February 2006 33

• Handling of HTTPS requests

• Impact of failure of the SAP Web dispatcher

Load Balancing

The SAP Web dispatcher has to decide which server can handle a particular request. Possible request might be for static web pages, for Business Server Pages, or for Java Servlets and JavaServer Pages (JSPs). Therefore, the SAP Web dispatcher has to distinguish whether to direct the request to an instance running ABAP or Java.

The SAP Web dispatcher can use the following information:

• URL prefix

The SAP Web dispatcher can direct the request to a group of servers according to a URL prefix. You can maintain the mapping of the URL prefixes in the Internet Control Framework (ICF) of the SAP Web Application Server (Transaction SICF). The SAP Web dispatcher uses the URL prefix to decide whether the request needs to be served by the Web AS ABAP (BSP) or the Web AS Java. If the URL prefix is not maintained in the ICF, the request is directed to a Java Server. The exception to this is when the prefix is only a /, which means that the documents are in the root directory of the web server, and the parameter is set to is/HTTP/default_root_hdl=abap.

• Logon group (only if configured for a URL prefix with transaction SICF)

When the request is directed to an ABAP server, this server is chosen from the specified logon group when its prefix is mapped to a logon group. Otherwise, any ABAP instance can be chosen.

When stateful sessions are used, the application state is bound to the session. This state is only available on one particular server that has to serve all requests of a session. Therefore. the SAP Web dispatcher has to make sure that all requests of a stateful session are handled by the same server.

The SAP Web dispatcher uses the session context to detect which session a new request belongs to and makes sure that all requests of a session are handled by the same server.

Within a group of servers the SAP Web dispatcher uses a weighted round-robin algorithm.

HTTPS Handling When the Web Dispatcher Does Not Terminate SSL Sessions (End-to-End SSL)

For end-to-end HTTPS sessions the SAP Web dispatcher does not read the session context because the relevant data is encrypted and is only decrypted by the application server. Therefore, the SAP Web dispatcher uses the IP address of the requesting client to make sure that all requests of a session are handled by the same server. As the SAP Web dispatcher is not able to decide whether the session is stateful or stateless it handles all sessions as stateful sessions.

The SAP Web dispatcher can refer to a logon group to find out which servers can handle HTTPS requests. It can use the profile parameter wdisp/HTTPS/dest_logon_group to point to a logon group containing only HTTPS enabled servers.

The SAP Web dispatcher maintains a mapping table where client IP addresses are mapped to application servers. The size of the table is configured with the profile parameter wdisp/HTTPS/max_client_ip_entries . When the table is full, all requests are dispatched to one dedicated server. There is a timeout parameter for table entries, wdisp/HTTPS/context_timeout. The default timeout value is 3600s. When an application server becomes unavailable the session context gets lost and a new server with a new IP address is assigned to the session.

When client requests arrive via a mega-proxy, requests belonging to one sessions might have different IP addresses. Therefore, a subnet mask can be used to declare IP addresses belonging to one mega-proxy. The parameter wdisp/HTTPS/sticky_mask configures this network mask.

As the SAP Web dispatcher cannot distinguish whether Java or ABAP requests have to be served, each server handling HTTPS requests has to have both stacks installed.

SAP Web AS ABAP

February 2006 34

When the computer running the SAP Web dispatcher is restarted, the IP/URL mapping table is lost. This leads to a failure of all active HTTPS sessions (when end-to-end HTTPS encryption is used), because the information about the servers is no longer available.

HTTPS Handling When the Web Dispatcher Terminates SSL Sessions (SSL Termination)

There is another option for HTTPS handling where the Web Dispatcher can terminate SSL sessions.

The SAP Web dispatcher decrypts the HTTPS request and then selects the server. You can define whether the request should be SSL-encrypted before forwarding it.

The option PROT in parameter icm/server_port_<xx> specifies whether SSL is terminated in the SAP Web dispatcher:

1. HTTP: The SAP Web dispatcher receives HTTP requests at the port.

2. HTTPS: The SAP Web dispatcher receives HTTPS requests at the port. It decrypts the request, before forwarding it to an application server.

3. ROUTER: The SAP Web dispatcher receives an HTTPS and forwards the request without unpacking it.

The wdisp/ssl_encrypt determines whether the SAP Web dispatcher encrypts the request again with SSL before forwarding it.

If you want your SAP Web dispatcher to unpack SSL or encrypt HTTP requests with SSL, you have to install the relevant SSL libraries and follow the configuration procedure. For more information, see the product documentation.

With SSL termination, there is no IP address table that can be lost in the event of failure. We recommend you to use SSL termination in high availability environments.

Start and stop of the SAP Web Dispatcher

To start a SAP Web dispatcher, you can use the following command: sapwebdisp pf=<name of the profile>

To stop a SAP Web dispatcher, you can use the following command: kill –2 <pid of the sapwebdisp>

The PID of the sapwebdisp process can be read from the file dev_webdisp.

To restart a SAP Web dispatcher, you can use the following command: sapwebdisp pf=<name of the profile> -shm_attach_mode <value>

where <value> is a number where the bits represent the following actions:

Bit Value Action

0 20 = 1 Delete 1 21 = 2 Attach

2 22 = 4 Create

http://aiokeh.wdf.sap-ag.de:1080/SAPIKS/~S~d6303ecdbf0f42f78ce663f593b1236b/KW/KW/IWB_EXTHLP~5F7A343CD46ACC68E10000000A114084/

SAP Web AS ABAP

February 2006 35

Combining the bits, the following actions are performed:

Value Action

1 Delete the shared memory of the SAP Web dispatcher (cleanup) 2 Try to connect to the shared memory (attach) 4 Attempts to create a table. 5 Deletes the existing table and creates a new table.

6 Attaches the existing table and – if there is no existing table – creates a new table.

The –shm_attach_mode parameter is only important when you don’t use SSL termination.

Impact of Failure of the SAP Web Dispatcher

When the SAP Web dispatcher fails, clients no longer have access to functions of the SAP Web AS using HTTP/HTTPS.

Automatic Restart of the SAP Web dispatcher

Therefore, the SAP Web dispatcher has to be restarted. The following command starts a second process when starting the SAP Web dispatcher: sapwebdisp pf=<name of the profile> -auto_restart

This second process monitors the SAP Web dispatcher process and tries to restart it in the event of failure.

If you want to stop the SAP Web Dispatcher, make sure that you first stop the watchdog process (this is started if you stop the other process). To do this, send a SIGINT to the watchdog’s PID. You can take this from the trace file dev_webdisp_watchdog.

Stopping the watchdog also stops the SAP Web Dispatcher work process.

If only the SAP Web Dispatcher work process is stopped with SIGINT, the watchdog starts this process again.

SAP Web dispatcher in a switchover cluster

You can achieve automatic failover by using the SAP Web dispatcher in a switchover cluster.

The following resources should be protected by the cluster:

IP address of the SAP Web Dispatcher

File system with the executable and the profile (alternatively, you can maintain both locally on each cluster node)

The application (start and stop mechanisms as described before). You can check the status of the process using the PID (you can find this in dev_webdisp or ev_webdisp_watchdog when using automatic restart)

SAP Web AS ABAP

February 2006 36


RDBMS


CentralInstance

ApplicationServers

DB Server

Fire

wal

l

Fire

wal

l

WebDispatcher

Standby

Switchover Cluster

Multiple SAP Web Dispatchers Behind an External Web Switch

Another way to achieve high availability for the SAP Web Dispatcher is to use multiple SAP Web Dispatchers behind an external web switch. This can make sense (despite the additional effort with external web switches) when you already use other web switches but want to use the simple configuration of the SAP Web Dispatcher.


RDBMS


CentralInstance

ApplicationServers

DB Server

Fire

wal

l

Fire

wal

l

WebDispatcher

WebDispatcher

Web switch(3rd party)

Another benefit from this approach is the scalability of the SAP Web Dispatcher.

Make sure that the web switch is also highly available.

3.3.4 Internet Communication Manager When the Internet Communication Manager (ICM) fails, the affected instance cannot communicate using Internet protocols. Communication using the dispatcher is not affected. The dispatcher restarts the ICM when it detects a failure. As the ICM does not hold state information, only active requests are affected.

As there is an ICM for each SAP Web AS instance, it is no SPOF and does not need further protection.

Sessions that have used the ICM get an error for a recurring request. Using the SAP Web dispatcher, the sessions are directed to another server. Using message-server based redirection, the user has to initiate a new redirection to access the message server.

Using the transaction SMICM, you can check the status of the ICM and administer the ICM:

Choose Administration J2EE Server to use the functions for managing the J2EE Engine.

To shut down the ICM, you can use the following commands:

SAP Web AS ABAP

February 2006 37

• Choose Administration ICM to soft-terminate (signal 2) or hard-terminate (signal 9) the ICM. With a soft termination, the ICM tries to send responses to its existing clients and then to close the connection. With a hard termination, the process is simply terminated. All existing connections and, of course, all requests are lost.

• Choose Administration Dispatcher Force ICM restart to force the dispatcher to restart the ICM if the ICM terminated due to an error.

For more information, see:

SAP Library SAP NetWeaver Solution Life Cycle Management System Management Administration of the Internet Communication Manager

Services and Hostnames in ICM

Depending on the profile configuration the ICM can bind its services (HTTP, HTTPS, SMTP) to all IP addresses or a specific IP address (or hostname) on the host. If no HOST argument is set with the parameter icm/server_port_<xx> the service is bound to all IP addresses, otherwise to the specified HOST value.

For absolute URL-Generation and the HTTP Load balancing (e.g. with the SAP Web Dispatcher) the information about the services (port, hostname, protocol) is sent to the Message Server.

The hostname value is determined in these steps by ICM:

1. the value of parameter "icm/server_port_<xx>" is used, if specified

2. the value of parameter SAPLOCALHOSTFULL is used, if explicitly set in the instance profile

3. the value of parameter icm/hostname_full is used, if explicitly set in the profile

4. the Full Qualified Hostname (FQHN) of the operating system on this host is used

For a switchover configuration of the ICM, either the services should be bound only to the virtual hostname or the value of parameter SAPLOCALHOSTFULL should be set to the virtual hostname of this server in the instance profile.

3.3.5 Update Service

There are some prerequisites for setting parameters related to the update subsystem. They are described in the SAP Notes 7209 and 39412.

Impact of Failure

With asynchronous transactions run, a user enters data in one or several screens. When the data is saved, an update request is created. The update service is then notified to actually execute the transaction in the database system. Two types of failure can occur:

• If the update task fails, for instance due to host failure, an express mail is sent to inform the user of the unsuccessful termination of the update task. The update task remains in the failed status in the system (VBLOG). You can check the status with transaction SM13.

• If the dialog instance fails before the user has finished inputting and saving the update task, all input is lost and must be re-entered manually. No update request is created and the information about the update is deleted from the database by the system internally.

Use one of the release-dependent options described below to make the update subsystem more resilient to failures.

SAP Web AS ABAP

February 2006 38

Distributed Update Services and Load Balancing

For more information on configuring multiple update servers within your SAP system, see SAP Note 7209.

Several update work processes can coexist in the system, distributed (or mapped) across several machines (that is, the CI or several AS machines). When a transaction has finished, the update request is created and a notification is sent to one of the update servers available within the SAP Web AS system. The server is chosen from the message server list (SM51) of application servers with configured update services. This means that the assignment of a host to perform an update task is dynamic and not determined by rdisp/vbname.

There are several ways to take advantage of load balancing to make the update service failure resilient. You can configure:

• Only the CI as the dedicated update server. The CI uses virtual addressing and is protected by switchover software. The SAP Web AS system then makes sure that update requests are sent to the CI for all switchover situations.

• Several external AS hosts so that they include update work processes. Load balancing makes sure that the update service is accessible on one of the AS machines, so virtual addressing is not needed to protect the update service.

• Both the CI (which uses virtual addressing) and external AS hosts to include update work processes. Switchover and load balancing together then make sure that the update service is failure-resilient.

For more information on the update service, see the online documentation of the SAP Web AS:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) ABAP Technology Client/Server Technology Updates in the SAP System

3.3.6 Batch Service

Impact of Failure

If a failing node has a batch job running on it, the batch job is aborted. You need to check the status of batch jobs in transaction SM37 and react to any unplanned termination. You also need to re-schedule the job manually. After a system crash, a batch job might remain in the status “running.” You can correct this in transaction SM37 by choosing Job → Check status.

Whether you need to reschedule a periodic job does not depend on whether the job has successfully completed. A periodic job is rescheduled, if it starts at all, no matter what happens after the start. Apart from this, for periodic jobs with dedicated target hosts the same applies as for normal jobs with dedicated target hosts.

Batch Jobs Not Scheduled on Dedicated Hosts

Automatic load distribution is performed for those batch jobs that are not scheduled on a dedicated host. A batch job that is not scheduled to run on a particular SAP Web AS instance is sent to a dynamically chosen SAP Web AS instance with a free batch work process.

For this reason we recommend you to configure several host machines with batch work processes. This avoids a SPOF for the batch service and makes it failure resilient. The SAP Web AS system automatically distributes work across the available batch work processes on the system.

Batch Jobs Scheduled on Dedicated Hosts

Distinguish between host and server. In this context a host is a physical machine, and a server is a SAP Web AS instance.

Several SAP Web AS instances can run on one host.

SAP Web AS ABAP

February 2006 39

You must schedule batch jobs relying on specific resources that are only accessible on a certain host by explicitly specifying the target host / target server.

To safeguard such jobs, install the dedicated SAP Web AS instance on a cluster node that uses a virtual host name and switchover software for failure protection. We explain this approach in the next section.

If you take these precautions, job scheduling can survive a switchover. Scheduled batch jobs are started on the new host after a switchover without requiring manual intervention, assuming that the job was not already running at the time of failure. In this case the remarks made above in Impact of Failure [Page 38] apply.

The advantage of a batch service switchover is restricted to service resources that are relocated together with the SAP Web AS component, or resources that can also be accessed transparently from the new host machine.

If a printer batch job tries to access a printer that is not directly accessible from the new host machine after switchover, the job obviously fails. To avoid this problem with printers, do not attach them directly to a specific host machine. Instead provide printers with their own network connection that can be transparently accessed after host machine switchover. For more information on how to make spool services failure resilient, see the documentation SAP High Availability SAP High Availability SAP High Availability [Page 8].

Scheduling Batch Jobs on a Dedicated Host in a Switchover Environment

To schedule a batch job to run on a certain instance, you have to specify a server. The possible values are shown in the value help for the target field in transaction sm36.

To enable switchover, you have to set the host name and instance names on the switchover machine appropriately with virtual addressing, because the host or server name is used to start a job on the dedicated target.

With virtual addressing the user does not need to make any changes to a batch job after a switchover.

Note the following comments about SAP batch job scheduling and virtual host names and addresses:

• You schedule a batch job in SM36 and check whether the job has successfully completed in SM37.

• The host or server names that appear when you choose F4 for the target field in SM36 are retrieved from the message service. They can be local or virtual.

• The host or server name that you enter can be local or virtual.

3.3.7 Spool Service For more information on how to make the spool service failure resilient, see the documentation SAP High Availability SAP High Availability SAP High Availability [Page 8].

Impact of Failure

A printer defined in the SAP Web AS is connected to a SAP Web AS instance that formats the printout in its spool work process.

When a SAP Web AS instance with a spool work process fails, all printers that are linked to it become inaccessible. Active print requests at the time of failure are aborted, so that you need to release them again manually after the switchover.

You can change the name of the application server of an instance running a spool work process (that is, spool server) in the database. You can re-assign the printer to a different server in the event of failure by calling transaction SPAD and choosing Utilities → For output devices → Assign server.

Configuring Printer Services with Virtual Addressing

To increase resilience of the spool and print service, you can use virtual addressing for the application server name of the SAP Web AS spool instance, which is normally the CI. For more information on

SAP Web AS ABAP

February 2006 40

how to setup application server names for virtual addressing, see Virtual IP Address Takeover [page75]

It is essential to keep the printer device accessible for the spool work process. Therefore, do not attach printers directly to a specific SAP Web AS host machine. Instead attach them to a print server that remains transparently accessible with a constant network name after switchover on the SAP Web AS cluster.

Use transaction SPAD to define a printer.

Logical Spool Server Definitions

It is possible to configure logical spool servers within transaction SPAD. For a failover configuration, these logical spool server definitions can be used to switch a spooler service from a failed application server to an application server that is still running. This switchover occurs automatically, minimizing interruption to print processing.

For more information on logical spool server concepts, see the SAP Printing Guide in the SAP Library and in SAP Note 118057.

3.3.8 Further ABAP Related Services

RFC

When an SAP Web AS instance is started anywhere in an SAP Web AS system, an entry is made in the table RFCDES with its application server name in the usual format <hostname>_<SID>_<NR>. The table RFCDES is used to store possible logical destinations for RFC calls. The instances within the same SAP Web AS system are also called internal RFC destinations.

The application server is used directly for RFC addressing. If configured correctly, the application server name is <virtual hostname>_<SID>_<NR> and virtual addressing provides transparent addressing for RFCs in all switchover situations.

The table RFCDES has the following fields:

RFCDEST contains a unique name for the logical destination.

• RFCTYPE contains the destination type:

− I for internal – same SAP system

− 3 for external SAP system

− 2 for external R/2 system

- T for TCP/IP connections, and so on.

• RFCOPTIONS contains additional information, dependent on the type.

Internal Destinations

For internal (RFCTYPE=I) destination calls within the same SAP Web AS system, RFCOPTIONS contains the IP address or host name and service number of the instance that is to be called. For an internal destination, the RFCDEST field is parsed for the address information before looking into the RFCOPTIONS field. Therefore, the address information in the RFCDEST field overrides the RFCOPTIONS field. Accordingly, in a switchover environment the RFCDEST field should contain <virtual hostname>_<SID>_<NR>.

R/3 Destinations

To access different, external SAP systems, another type of logical RFC destination is used, RFCTYPE=3.

SAP Web AS ABAP

February 2006 41

You can choose between addressing a specified host machine directly or with load balancing, where the SAP Web AS chooses the host itself. If you select load balancing in transaction SM59, you do not need to enter a host name as described above – this is the recommended configuration. The procedure for choosing a host is similar to that for logon load balancing where the list of hosts on the message server is accessed.

CCMS

In the Computing Center Management System (CCMS) you can define operation modes for SAP Web AS instances. An operation mode defines a resource configuration for the instances in your SAP Web AS system. It can be used to specify which instances are started or stopped and how the individual services are allocated to each instance in the configuration. An instance definition for a particular operation mode consists of the number and types of work processes as well as start and instance profiles. CCMS lets you perform profile maintenance from the SAP Web AS system.

When you define an instance for an operation mode, you need to enter the host name and the system number of the application server. By using the virtual host name for the host name field, the instance can continue working under control of the CCMS after a switchover without requiring any changes.

If an AS instance is running on a standby node for a CI, DB, or CI/DB instance during normal operation, the AS is normally stopped when the CI or CI/DB is switched over. If so, the control console indicates that the AS instance is not functioning with a red light.

To maintain operation modes in a switchover environment proceed as follows:

• Use the CCMS transaction RZ04 to create operation modes and instances. First create a mode, for example, “Day” for daytime operation.

• After creating an operation mode, maintain the timetable for your modes by defining the time at which the mode is to be activated. When you define the instance, enter the virtual host name in the field host name.

SAPCOMM Services

It is difficult to give specific recommendations because the implementations for attaching services to sapcomm depend on the hardware chosen, which means they differ widely.

Attaching services like fax to the sapcomm process is similar to the procedure of attaching printers to the spool service. The basic methods of making a service more failure resilient are described above in the Spool Service [Page 39] and Batch Service [Page 38].

SAProuter Services and WAN Access

Functionality and Impact of Failure

The saprouter process is normally run on a firewall machine:

• Firewalling provides security by protecting your host machines from direct access from the outside WAN for security reasons. Only the firewall machine is visible on the WAN.

• The saprouter allows network traffic for authorized SAP processes to go through the firewall by permitting:

− WAN access from the SAP Web AS system to the outside network

− Access to the local SAP Web AS services, for example, front-end connects from the WAN

If the firewall machine running the saprouter process fails, any WAN network traffic to or from the local SAP Web AS system is impossible.

For more information on SAProuter, see the online documentation of the SAP Web AS:

SAP Library SAP NetWeaver Solution Life Cycle Management System Management Saprouter

SAP Web AS ABAP

February 2006 42

Making WAN Access Failure Resilient

You can use the following methods to make WAN access failure resilient in the SAP Web AS system:

• Provide redundant firewall machines. If the stationary firewall machine fails, reconfigure the standby to take over the task. In most cases it might be sufficient to prepare this takeover and for the administrator to execute it when it is actually needed.

• Provide two firewall machines and configure the SAP Web AS system to run one saprouter process on each machine. If the first firewall crashes, currently active WAN access is interrupted, but can be restarted through the second firewall. Note that the second path must be defined and known to the outside world, that is, to external WAN users.

• If WAN access is vital for the continuation of business, use the standard switchover methods – identity takeover or virtual IP address takeover. In this case, you need to dedicate an entire switchover cluster to the WAN access service.

You might only be able to justify this option if you have very demanding WAN access requirements. Firewalling and switchover software might not be compatible for some products. Consult your switchover software vendor to find out how to best protect the firewall machine against failure.

For security reasons, we do not advise running the saprouter on the normal SAP Web AS instance cluster together with the CI on a CI switchover host. In this case the CI machine with SAP Web AS on it would be visible to the outside WAN. Remember that making SAP Web AS instances invisible to the outside network was the primary reason for introducing a firewall in the first place.

For more information, see the documentation SAP High Availability SAP High Availability SAP High Availability [Page 8].

3.3.9 Problems and Solutions A number of problems relevant to switchover have been encountered in connection with the gateway service, message service, and ABAP variable SY-HOST. The following sections describe the problems, list the releases and platforms where they occur, and list solutions provided in later releases.

Gateway Service

The system must determine whether a program can be started locally on the same host or if an RFC call must be initiated that transfers program execution to another host. To make this decision, the host machine checks whether the RFC address matches one of its own names. If so, the RFC is performed locally.

On cluster hosts the gateway requires that host names that translate into virtual IP addresses are used. Otherwise it would be necessary to change the instance profile, if the instance is switched over to another host machine with different non-virtual names. Only virtual names stay constant and so comply with the transparent addressing techniques that are required by the SAP Web AS system. The host name configured as SAPLOCALHOSTFULL, if not set explicitly, contains the returned value of a gethostname system call as the default. This is read into gw/alternative_hostnames by default and means that you should configure SAPLOCALHOSTFULL to contain a virtual host name as well.

Gateway Limitations for Local Addresses

The gateway can only remember a limited number of addresses. The following limit applies:

512 addresses are stored in all R/3 Releases from 4.6D onwards (with patch level 878)

This limit can be a problem for systems that use virtual addressing, because they require many addresses. This limit has implications for the types of network setup that can be run with SAP Web AS in a switchover environment.

SAP Web AS ABAP

February 2006 43

The number of local addresses that must be known to the gateway at any given moment varies with the:

• Number of LANs used

• Number of stationary addresses used on one host

• Number of virtual addresses used on one host

• Switchover status, since the number of virtual addresses is increased if addresses are switched over to the local host machine.

In scenario SO-1 the CI switches over to the DB instance so that both the CI and DB then run on a single instance. This can occur in a single-LAN or two-LAN setup:

• Single-LAN setup

The virtual IP address of the CI is switched over to the DB host, which already holds 2+1 addresses. As a result, 3+1 addresses need to be held on the gateway of the DB host.

• Two-LAN setup

The 2 virtual IP addresses of the CI are switched over to the DB host, which already holds 4+1 addresses. As a result, 6+1 addresses need to be held on the gateway of the DB host.

‘+1’ above refers to the entry needed for localhost.

To look at the first five addresses held by the gateway, execute the following operating system command for the specified host machine as user <sid>adm:

gwmon pf=/usr/sap/<SID>/SYS/profile/<instanceprofile> nr=<NR>

Normally <instanceprofile> is <SID>_<INSTTYPE><NR>_<hostname>. The command provides a menu (letter m), where you select the letter y to display system information. This option returns a list of all gateways in the SAP Web AS system and the host names configured on them. Look for the entry of the LOCAL_R3, in the last column called hostname(s), to find out the host names and addresses that are held by the local gateway. Note that the gwmon tool only lists a maximum of five addresses, even if more addresses are actually known to the gateway.

To check the number of addresses held by the gateway process, you should perform the test described in Local Gateway Addresses [Page 124].

ABAP Variable SY-HOST

The SY-HOST variable is set to the value of SAPLOCALHOST. The virtual host name is used without problems if you have configured SAPLOCALHOST accordingly.

SAP Web AS Java

February 2006 44

4 SAP Web AS Java

Contents 4.1 Protecting System-Critical Components ......................................................................44

4.1.1 Switchover Units............................................................................................................................... 45 4.1.2 Failure and Switchover of SAP Web AS Units ................................................................................. 45

4.2 Switchover Scenarios ...................................................................................................46 4.2.1 HA Installation Scenario Rules......................................................................................................... 46 4.2.2 DB and SCS in One Switchover Unit ................................................................................................ 47 4.2.3 Scope of Switchover Scenarios ....................................................................................................... 50 4.2.4 Hardware Requirements ................................................................................................................... 50

4.3 Service Configuration for Increased Failure Resilience...............................................51 4.3.1 Message Server Proxy ...................................................................................................................... 51 4.3.2 Software Delivery Manager............................................................................................................... 51 4.3.3 Web Container .................................................................................................................................. 52 4.3.4 EJB Container................................................................................................................................... 53 4.3.5 Failover for Clustered RMI-P4 Remote Objects ............................................................................... 53 4.3.6 Naming Service................................................................................................................................. 54 4.3.7 Java Message Service ...................................................................................................................... 54

This chapter describes switchover for SAP Web AS Java.

There is a process for each configured server and the dispatcher. Each process runs a Java Virtual Machine (JVM). One server process includes several threads, where one thread normally represents one task. All threads within one process share the same memory that belongs to the process. When a server process fails, the context of all sessions running on this particular server is lost, except when session failover for web applications and Enterprise JavaBeans (EJBs) is used. However, the application can be continued on another server within the Java cluster

When an ABAP work process fails, only the current session that has been running on this work process fails, because the work process stores user contexts in shared memory

SAP Web AS Java 6.40 provides several J2EE-compliant services. In the following sections, we only describe the behavior in the event of failure of the most important services.

For more information on the architecture see the online documentation at help.sap.com:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) Java Technology in SAP Web Application Server Architecture Manual

4.1 Protecting System-Critical Components This section discusses how you can use switchover strategies to protect services that are of critical importance for the availability of SAP Web AS Java. Services that are critical for the operation of an SAP Web AS system are:

SAP Web AS Java

February 2006 45

• Enqueue service

• Message service

• Database Management System (DBMS)

• Network File System (NFS) service

These are also known as system-wide, single points of failure (SPOFs) because they cannot be configured redundantly. If a host running one of these services crashes, the service can be transferred to another host within the cluster using switchover software. This chapter explains how this can be done using switchover strategies and illustrates this with a set of standard switchover scenarios.

The protection of other SAP Web AS Java services that are not SPOFs is described in Service Configuration for Increased Failure Resilience [Page 51].

4.1.1 Switchover Units SAP recommends grouping the system-critical SPOFs in the SAP Web AS into the following switchover units:

• SCS + NFS – SAP Web AS Java central services (SCS) instance with enqueue and message service and network file system

• DB – database management system

In this chapter, we include NFS in the switchover scheme, whereas in other chapters we assume that it is part of the operating system and do not deal with it explicitly. For more information, contact your hardware and switchover product vendors.




DB/SCS/NFS Central system

DB SCS/NFS Mutual takeover, NFS on SCS node

DB/NFS SCS Mutual takeover, NFS on DB node

DB SCS NFS Separation of all services, NFS on dedicated server (Unix only)

When choosing an appropriate configuration for a switchover cluster, consider the points described below.

NFS Service

In a SAP Web AS system, several directories have to be NFS-mounted. In most cases either the database node or the central instance node act as the NFS server, but this depends on your database.

From the perspective of SAP Web AS, NFS is considered to be part of the operating system (OS) underlying SAP Web AS. Contact your vendor of OS and switchover software for help with setting up NFS correctly for your database. Although no installation guidelines are included in this documentation, you can find more information in Configuring NFS [Page 70].

4.1.2 Failure and Switchover of SAP Web AS Units The most critical units of the SAP Web AS are the SCS and the DB. Failure of a machine hosting one of these has a severe impact on the availability of the SAP Web AS system. The impact differs, depending on the unit that is affected:

SAP Web AS Java

February 2006 46

• SCS host failure

The most important result of this is the loss of the enqueue service. The locks held by the SAP Web AS Java are lost and the enqueue service has to be restarted (unless you are using replicated enqueue, described later in this paper). The complete system will restart after this

• Database host failure

This needs extra action from the application to use the database reconnect feature described in the high availability documentation mentioned in the following note.

For more information about SCS instance and DB failures and their consequences, see the online documentation at help.sap.com:

SAP Library SAP NetWeaver Solution Lifecycle Management SAP High Availability SAP SAP Web Application Server Java: High Availability SAP Web AS Java Failures

4.2 Switchover Scenarios The following sections deal exclusively with host failure and switchover of the DB and SCS units of the SAP Web AS Java. NFS is not extensively included in the examples because we consider it to be part of the operating system, which is handled externally by the switchover product. For more information on NFS see Configuring NFS [Page 70].

The switchover of application server (AS) services is not included in the SAP Web AS Java switchover scenarios because services that are of critical importance to your business on several AS hosts are redundantly configured by default. This makes sure that a single AS instance does not contain services that are critical system-wide SPOFs. Therefore, AS instances do not necessarily need to be part of the switchover cluster.

Heterogeneous operating system environments that run several different operating systems at the server level (SCS, DB, AS instances) introduce additional complexity into a switchover system.

To run the SAP Web AS in a switchover environment successfully, SAP strongly recommends that switchover actions only take place between equivalent operating systems. Switching between different operating systems is highly complex and we do not recommend it.

Assuming that the SCS is running under the operating system Microsoft Windows and the DB on a UNIX platform, then the SCS can only switch to another Windows machine and the DB to another UNIX machine. It is not permissible to mix these options, that is, to switch the SCS to UNIX or the DB to Windows.

Here we only consider switchovers performed in a two-node cluster. This type of setup is sufficient for test purposes. Clusters including more host machines allow more complex setups for switchover. The two-node examples provided can be used as basic building blocks to construct other types of switchover setups.

4.2.1 HA Installation Scenario Rules The following section provides detailed information about the installable software units and also contains specifics for ensuring high availability of these units. However, the possible installation

SAP Web AS Java

February 2006 47

scenarios are too many to be described, thus the most used installation cases are listed in this section.

Fixed scenarios cause permanent demand for clarification. Therefore, the following set of rules can help you test your scenario. These rules are meant for different operating systems and some of them may be obsolete for your operating system.

1. DB and Java SCS/ABAP SCS should run in different switchover groups Ddatabases have significant impact on switchover due to processing of transaction logs, thus it is not recommended to include them together with other components into a switchover unit. The SCS services do not use or need a lot of resources, therefore they can be switched very fast. Because of this it is a good idea to have independent switchover groups for both services.

2. Java SCS/ABAP SCS instances should be in a single switchover group As SCS Instances contain quite small processes which are very important to the whole environment it is recommended to keep them alone in their switchover group. Thus eliminating that case that SCS instances have to wait for larger processes get running.

3. AS may run in a switchover group It is possible to run an application server in a switchover group, but not necessary. In case of a switchover, all user sessions will be lost if the application does not support session persistance.

4. Several switchover groups may run on the same hardware cluster. It is possible to run several switchover groups on one hardware cluster (if your HA software allows this). It is also an option to distribute them on several hardware clsuters.

5. The use of enqueue replication server is strongly recommended. The enqueue service handles locking in the application server. In case the service fails and is not replicated, there may still be running processes in the system that continue to use old locks. To keep integrity, the server restarts as soon as it detects such situation. Although, this detection only can appear when contacting the enqueue service, there is a possible short timeframe of risk. By using a replicated enqueue server, this risk is completely avoided and integrity can be assured under all circumstances.

6. If ABAP-CI exists, it has to be in a switchover group. This is only relevant for installations that shall be made high available at a later point in timeand have been installed in standard mode. In this way, the SPOFs are part of the main process that defines the old central instance. You either have to follow this rule or reinstall your system in HA mode.

7. Additional AS may serve the same SAP System It is possible to have additional non-protected application servers in the same system, either on additional hardware or on the hardware cluster. This does not influence on high availability issues and is only relevant for performance.

4.2.2 DB and SCS in One Switchover Unit

DB and SCS Each in its Own Switchover Unit, Java-CI Outside

The general and important nature of this scenario is the separation of database and SCS instance into their own switchover group. The first variant keeps the Java CI outside of the hardware cluster, thus only running necessary parts for switchover in such environment.

In this scenario the Software Delivery Manager (SDM) might now been seen as a SPOF. However, as we describe later in this chapter, we do not regard the SDM as a SPOF, although it only has a single process in the environment. SDM is used to deploy new software versions, which we assume to be non-critical for production environments. As software updates already imply “planned downtime” we prefer to describe it under this heading.

SAP Web AS Java

February 2006 48

DB and SCS Each in its Own Switchover Unit, Java-CI Outside

Database

Java Schema

Database Processes

Database Processes

SCSJava-CI installed

outside the switchover environment

ENQ and MSG Server are separately installed within its own switch-

over unit

Java-CI

SAP Rating: RECOMMENDED

DI DI

.

A variant of this scenario is to include server instances into hardware cluster hosts. These are not included in switchover units. In case of fail over the server processes are not regarded. The variant is meant for using up the power of the cluster hosts if the database and SCS do not already.

It may be of advantage to only run a server instance on the idle host and use the switchover software to shut down the running server instance before switching. Thus, the power of both hosts can be used optimal.

SAP Web AS Java

February 2006 49

DB and SCS Each in its Own Switchover Unit, Java-CI Inside

Database

Java Schema

Database Processes

Database Processes

Java-CI installed on switchover host, doesn’t

switchover itself.

On the other host a Java-AS is installed

ENQ and MSG Server are able to switchover.


AS AS

For systems with a high load it is a good idea to think about assigning database and SCS processes to different hosts for performance reasons. If you are concerned about machines running in idle mode, consider that some systems allow running this environment on three machines, by running only one computer in idle state. In the event of switchover either the database or the SCS instance switches to the computer that is currently idle.

SAP Web AS Java

February 2006 50

DB and SCS Each in its Own Switchover Unit, Two Switchover Environments

Java-CI installed outside the switchover

environment

SCS

Database

Java Schema

Database Processes

Database Processes

DB


The database has its own switchover

environment and switchover unit

ENQ and MSG Server are separately

installed within its own switchover

unit

Java-CI

AS AS

4.2.3 Scope of Switchover Scenarios You might want to construct more complex setups than the ones given above to meet your specific requirements. Although such setups are not explicitly part of the test scenarios, you can put together complex setups by using these scenarios as the basic building blocks.

The scenarios listed cover all the main configurations of SAP Web AS Java switchover between two cluster machines.

4.2.4 Hardware Requirements It is important to adequately equip host machines within a switchover cluster. Sufficient CPU power, RAM, I/O capacity, network capacity, and so on, must be available if a switchover occurs and the machine that is taking over another component has increased demands. This applies especially to scenarios where one machine takes over the workload that was previously handled by two machines. It might also be relevant when an application server substitutes a SCS or DB instance after switchover.

Generally, make sure that even in a switchover situation the hardware is adequately sized to run the increased workload. You might be able to accept some performance loss in emergency cases. However, it is unacceptable if the system comes to a standstill because it is overloaded after switchover.

Depending on the switchover scenario chosen, the underlying hardware might require oversizing to run the switchover cluster successfully. In some cases it might be advisable to provide identical standby machines for critical server machines. These could be idle, run non-critical services, or serve as additional AS instances.

SAP Web AS Java

February 2006 51

In accordance with the scenario definitions, the following minimal hardware configuration is necessary to run and test the SAP Web AS in a switchover environment:

• A two-node switchover cluster

• One or two additional cluster-external host machines, depending on the scenario

4.3 Service Configuration for Increased Failure Resilience

4.3.1 Message Server Proxy In architectures before NetWeaver 2004 SP 16 all processes of an J2EE-Instance had separate connections to the SCS (ENQ/MSG-Server). Therefore as installations get bigger there are a lot of network connections.

There is a risk of processes detecting lost connections asynchronously. For example, if a broken connection to the Enqueue or Message server is detected this will result in dropping a server node due to a timeout. In this case JControl is not aware of the already happening restart and once it becomes aware it is sending a signal to the node to restart, which also affects nodes being restarted already.

Therefore the MSG-/ENQ-Proxy concept is introduced

All connections will be handled via JControl as proxy. There is only one proxy per instance, which results in less connections and synchronous detection of failures. This in turn will avoid „out of synch“-error handling for connections from the instance to the ENQ/MSG-Server and cluster internal connections

The use of this functionality is optional with SPS16 and will become standard with future releases

Activation of the Proxy can be done by setting the respective profile parameter from the following list:

Profile parameter value

jstartup/proxy Comma separated list {en|ms}: - empty: (default) no proxy service - en : establish enqueue proxy - ms : establish message proxy

4.3.2 Software Delivery Manager The Software Delivery Manager (SDM) is used to deliver applications for the SAP Web AS Java. It is part of the Java CI. If the Java CI is not available, you are not able to deliver applications for your SAP Web AS Java.

You can handle the Java CI as an additional unit of failover. This ensures that this instance is available continuously and can always be used.

However, delivery to a production system should be a planned process where you make sure that SDM is available without the help (and the configuration effort) of switchover software. Additionally the deployment process involves planned downtime anyway, since a software update requires a system restart. Therefore, we do not recommend the switchover configuration of the Java CI as a general option and do not describe it in detail.

The SDM stores information about its delivery history in its local file system. If these files are not available this can cause problems with future deliveries.

SAP Web AS Java

February 2006 52

We strongly recommend you to perform regular backups of the following directory tree:

/usr/sap/<SID>/<instancename>/SDM

Perform a backup after each delivery to keep a record of all changes.

4.3.3 Web Container

Overview

SAP Web AS Java provides services that can be accessed with a Web browser using HTTP/HTTPS. SAP Web AS Java includes a Web Container that enables the execution of Java servlets and JavaServer Pages (JSPs). As JSPs are translated into servlets, they follow the same principles as servlets.

Within an SAP Web AS Java cluster, all Java processes have the same J2EE components available. They are deployed in parallel and the cluster elements use the database as a central information store. This means that all servers in the cluster share the same information.

Therefore, it does not matter which server in a cluster is accessed to provide HTTP services. However, you need to distinguish whether stateless or stateful servlets are accessed:

• Stateless servlets have no application state that is bound to the session. Therefore, every server in the cluster can run stateless servlets. When a server fails, the next request for the servlet is directed to another server that handles the request without loss of session data.

• Stateful servlets have an application state that is bound to the session. For these servlets you can implement HTTP session failover so that session state is serialized and written to persistent storage (either the database or the file system). Therefore, if the server where the

J2EE Components

Web Browser

Web Server

JSP & Servlet Engine

R

HTML Pages

R

JavaServlet

JSPProcessor

RR

Java ServerPages

Application

JNDI Context

Session Bean

Entity Bean

R

R

RR

R R

HTTP TCP IP

SAP Web AS Java

February 2006 53

session was active fails, the session state can be retrieved on another server using the database.

For more information about HTTP session failover, see the SAP Web AS Java documentation [Page 9] at help.sap.com:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) Java Technology in SAP Web Application Server Architecture Manual Java Cluster Architecture High Availability and Failover Failover for J2EE Web Applications.

4.3.4 EJB Container During application deployment, EJBs are deployed on all server processes in the cluster. For each call to an EJB, a system external to the EJB Container dispatches the call to an EJB instance on a particular server process. This instance works locally – that is, it is not aware of the availability of other EJB instances in the cluster.

If the server process where the instance resides fails, then the call must be redirected to an available server process where a new EJB instance processes it. The redirection is transparent to the EJB.

Session Beans

Session Enterprise Java Beans (EJBs) in the Web AS Java work locally and independently of each other. They are not clustered and do not communicate with other session EJBs on other server nodes in the cluster.

Failover for stateless session beans is provided by the RMI-P4 protocol, which redirects the call to an available server process. However, state preservation is available for stateful session beans through the failover system of the Web AS Java. The bean instance is serialized and stored in a persistent storage and that makes it possible to restore the state after the call has been redirected to an available server process by the RMI-P4 protocol.

For programming prerequisites, see the Development Manual of the SAP Web AS Java [Page 9] at help.sap.com:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) Java Technology in SAP Web Application Server Development Manual Developing Business Logic Developing Enterprise Beans

Entity Beans

The state of an entity bean is kept in the underlying database. This is the last committed state. Therefore, the new bean instance that is to process the call after the failover retrieves the last committed state from the database.

4.3.5 Failover for Clustered RMI-P4 Remote Objects RMI-P4 provides a transparent failover for clustered remote objects where all actions are performed on the server side. It implements a mechanism for migrating instances of those objects to other available server processes within the SAP Web AS Java cluster when a server process crashes.

SAP Web AS Java

February 2006 54

Client JVM

Client

Stub

Load Balancing Framework

J2EE Dispatcher

P4 ORB

RemoteObject

J2EE Server

P4 ORB

RemoteObject

J2EE Server

Cross System

This mechanism does not preserve the state of the object after migration. This remains the developer’s responsibility.

To call methods on a remote object, a client has to obtain an object reference. The reference contains information about the identifier associated with the remote object by the naming system. If a server process crashes, the remote object is no longer available. If the Java dispatcher receives a new request, the request is directed to a surviving server process. However, there is no instance of the requested object.

The P4 broker object on the new server process gets the identifier of the remote object from the request and contacts the cross system. The cross system looks up the remote object and provides the P4 broker with access to the class loader of the remote object. This means that an instance of the remote object is created on the new server process and client-server communication continues as usual.

4.3.6 Naming Service The Java Naming and Directory Interface (JNDI) Registry Service provides failover by redirecting clients to a context instance on an available server process.

Remote clients use the JNDI Registry Service of one of the server processes in the cluster through a context instance. This instance is connected to the naming system of the server process and all naming operations are performed there.

If the server fails, the JNDI Registry Service redirects naming operations to another server for processing. The redirection is transparent to clients.

4.3.7 Java Message Service Java Message Service (JMS) clients create connections and then send or receive messages using the server-side JMS provider infrastructure. Infrastructure failures can cause connection loss and communication disruption.

JMS failover notifies clients when such a failure occurs. However, failover is not transparent to clients because they have to re-establish their connections to the JMS provider.

JMS clients have to implement the ExceptionListener interface, which enables them to receive a JMSException that is raised in the event of failure. The client application can then restore its

SAP Web AS Java

February 2006 55

connections to the JMS provider without having to close the old connection by implementing the onException method of the ExceptionListener interface.

HA Considerations for Integration Scenarios

February 2006 56

5 HA Considerations for Integration Scenarios

Contents 5.1 Integrated Scenario .......................................................................................................56

5.2 Separate Systems .........................................................................................................58 5.2.1 ABAP/Java Communication via the SAP Java Connector (JCo)...................................................... 58 5.2.2 High Availability Considerations for Web Services ......................................................................... 60

5.1 Integrated Scenario The integrated scenario for the SAP Web AS comprises a SAP Web AS, where ABAP and Java stacks are installed in parallel within the same system.

SAP Web AS - IntegratedInstallation

Central Instance

Java ABAP

ICM

Dispatcher Dispatcher

WorkProcesses

WorkProcesses

WorkProcesses

ServerNodesServerNodes

ServerProcesses

SDM Gateway

EnqueueService

MessageService

Central ServicesJava

EnqueueService

MessageService

RDBMS

SAP recommends grouping the system-critical SPOFs in the SAP Web AS into the following switchover units:


February 2006 57

Unit Description

SCS SAP Web AS Java central services instance with enqueue and message service

CI Central instance (combined for ABAP and Java stack, containing message and enqueue service for the ABAP stack and SDM for the Java stack plus several work processes and Java Server processes)

DB Database management system

NFS Network file system

We consider DB and NFS services to be separate service packages. Depending on how many host machines are available in the switchover cluster, there are several ways to distribute them. In this chapter, we include NFS in the switchover scheme, whereas in other chapters we assume that it is part of the operating system and do not deal with it explicitly. For more information, contact your hardware and switchover product vendors.




DB/SCS/CI/NFS Central system

DB SCS/CI/NFS Mutual takeover, NFS on SCS/CI node

DB/NFS SCS/CI Mutual takeover, NFS on DB node

DB/SCS CI/NFS Mutual takeover, NFS on CI node

DB/SCS/NFS CI Mutual takeover, NFS on DB/SCS node

DB/CI SCS/NFS Mutual takeover, NFS on SCS node

DB/CI/NFS SCS Mutual takeover, NFS on DB/CI node

DB SCS/CI NFS Separation of all services, NFS on dedicated server

For customers using Informix as database platform for the ABAP stack, a second database instance running on a different database platform is required for the Java stack. Make sure that you consider this database instance in your switchover concept.

For more information on supported database platforms, see the SAP Service Marketplace at the Internet address: service.sap.com/platforms

The following graphic shows a configuration with an integrated SAP Web AS running in a 2-node cluster.


February 2006 58

SCS + CI

Central Instance

J2EE ABAP

ICM

Dispatcher Dispatcher

WorkProcesses

WorkProcesses

WorkProcesses

ServerNodesServerNodesServerNodes

SDM Gateway

EnqueueService

MessageService

Central ServicesJ2EE

EnqueueService

MessageService

DB

RDBMS

Failover

Failover

Failover

5.2 Separate Systems For an installation of two separate SAP Web AS systems, consider high availability measures separately for each involved system. However, both systems communicate using interfaces that have separate high availability features. The interfaces are described in this chapter.

5.2.1 ABAP/Java Communication via the SAP Java Connector (JCo) SAP provides the SAP Java Connector (SAP JCo) to enable communication between ABAP (of an SAP Web AS) and Java. This can obviously be used for the internal communication of the SAP Web Application Server where the ABAP personality and the Java servers interact using SAP JCo.

You set up the JCo by registering the Java server as an RFC server to an SAP Gateway. This method works in both directions:

• Inbound

Java calls BAPIs and RFC-enabled Function Modules (RFM) on the ABAP side and acts as a client). In this case it is the Java application that initiates the connection. In case of switchover on the Java side, the connection is lost and the application needs to re-establish it.

• Outbound

ABAP calls functions on the Java side, which acts as a server. In this case, switchover of the Java side is transparent as the JCo RFC Provider Service is started on the new host. The configuration


February 2006 59

settings of the RFC destination and the repository are also preserved as they are recovered from the database of the Web AS Java.

The basis for this communication is the Remote Function Call (RFC). JCo supports synchronous, transactional, and queued RFC.

Calls from the SAP system are processed by the JCo RFC Provider Service of the J2EE Engine. It dispatches the call to a stateless session bean, which is registered in the Java Naming and Directory Interfaces (JNDI). Following the naming convention, the JNDI name used is identical to the name of the SAP function module. To parse the function calls from the SAP system correctly, the JCo needs access to an SAP system repository.

Scenario

Scenario:

1. On startup of the JCo RFC Provider Service (this is normally the startup of the Java server), the service connects to the SAP system repository.

2. On startup, the JCo RFC Provider Service registers itself at the gateway with a defined name. It is possible to register under different names and at different gateways. But note that there is only an 1:1-relation between a name and a particular gateway. This has implications for high availability that are discussed below.

3. An SAP system calls a function for the registered RFC destination. The function has to be defined in the repository.

4. The gateway forwards the call to the JCo RFC Provider Service.

5. The JCo RFC Provider Service looks in the JNDI for the EJB, which is registered under the same name as the function module in the SAP system.

6. The JCo RFC Provider Service calls the method JCO.Function.processFunction of the EJB.

7. The results of the call are passed to the gateway.

8. The gateway passes the results back to the SAP system.

Gateway/JCo Relationship

The JCo RFC Provider Service can be registered under one name to one particular gateway. To be registered to another gateway, another name has to be used.

In the SAP system, you can configure an RFC connection under one name for one particular external program that has to be registered at the gateway. Optionally you can specify a particular gateway for the connection.

J2EE Engine

JCo RFC Provider

JCo

JNDI Context

EJB

repository

GatewaySAP System

RDBMS

1

2

345 6

78


February 2006 60

J2EE Cluster

J2EE server 1 Gateway 1

program 1

rfc connection 1

J2EE server 2 Gateway 2program 1

rfc connection 2

J2EE Servers in a Cluster

program 2

program 2

Within a Java cluster, all Java servers configure the JCo RFC Provider Service identically. This means that a particular program registration is valid on all servers and points to the same gateway. The gateway is able to balance requests between different servers that are registered under the same program name. For more information, see SAP Note 63930.

If one Java server fails, the RFC connection still works with the other servers in the cluster. However, if the gateway fails, the RFC connection no longer works, because a particular program name can only be registered at one particular gateway.

There are different deployment options for the gateway:

• Each SAP instance has its own gateway service (sapgw<systemnumber>) where external programs can be registered.

• With the standalone SAP Gateway, you can install the gateway service separately from the SAP system, for example, on the same host as the Java server(s). In this case, the SAP system can access each external gateway under a different RFC connection.

Choose the deployment option according to your application scenario. When you use an option with different RFC connections, the ABAP application has to be aware of this.

Relevant SAP Notes

Note Number Topic

497427 32-bit compatible UNIX shared memory parameters

538544 Problems in communicating via the FastRFC protocol

529088 Patches for the SAP J2EE Engine

5.2.2 High Availability Considerations for Web Services As web service communication is based on protocols on top of HTTP, all high availability measures described for load balancing apply. For more information, see the relevant chapters.

Installing SAP Web AS in Switchover Environments

February 2006 61

6 Installing SAP Web AS in Switchover Environments This chapter describes the main steps that you need to perform when installing the SAP Web AS in a switchover environment.

Contents 6.1 Installing SAP Web AS Switchover Units .....................................................................61

6.1.1 Preparing the Installation ................................................................................................................. 61 6.1.2 Performing the Installation for ABAP and add-on ........................................................................... 62 6.1.3 Adapting Scripts and Profiles .......................................................................................................... 63 6.1.4 Performing the Installation for Java only......................................................................................... 64

6.2 SAP Web AS File Systems and NFS..............................................................................66 6.2.1 SAP Web AS File Systems................................................................................................................ 66 6.2.2 SAP Web AS ABAP: Creating Local Executables (sapcpe) ............................................................. 69 6.2.3 Configuring NFS ............................................................................................................................... 70

6.3 SAP Web AS License ....................................................................................................71 6.3.1 Standard Licensing Procedure ......................................................................................................... 71 6.3.2 Licensing in Switchover Environments............................................................................................ 72

6.4 Additional Tasks for SAP Web AS ABAP......................................................................73 6.4.1 Transport Control ............................................................................................................................. 73 6.4.2 Upgrading ......................................................................................................................................... 73

6.1 Installing SAP Web AS Switchover Units

Before you plan the installation, we recommend that you read the documentation SAP High Availability [Page 8], which deals with all subjects related to the availability of SAP Web AS systems. This is part of the standard SAP documentation package delivered with the SAP Web AS. For more information on configuring the system once it has been installed, see Switchover System Configuration [Page 85].

6.1.1 Preparing the Installation When you plan the installation, make sure that the hardware is adequately sized to handle the increased workload resulting after a switchover. You might be able to accept some reduction in performance in an emergency. However, it is not tolerable if the system comes to a standstill because it is overloaded after switchover.

Before beginning the installation you:

• Decide how to distribute the database and central instance over the cluster nodes. Also decide which node will be the Network File System (NFS) server.

• Make sure you are using the virtual host name for NFS to enable NFS switchover.

• Install the hardware (that is, hosts, disks, and network).


February 2006 62

For Web AS 6.40 Java there are some additional tasks:

• Assign the local disk partitions/volumes to drive letters or mount points

• Assign the shared disk partitions/volumes to drive letters or mount points within the appropriate cluster groups/package.

• Assign the virtual IP addresses and hostnames for SCS, DB, NFS and/or Cluster to the appropriate cluster groups/packages.

• On Unix only: Export and re-import the sapmnt NFS to both cluster nodes.

How the resources can be assigned to a cluster group/package is described in detail in the HA partner documentation.

Enabling Remote Logons

To run certain operating system commands as user root and <sid>adm you have to allow remote logons from user root to user <sid>adm.

On UNIX platforms you have to create the file .rhosts in the home directory of <sid>adm on each host machine as follows: host1 root

host2 root

This allows the user root to perform a remote logon to the <sid>adm account from both host1 and host2.

6.1.2 Performing the Installation for ABAP and add-on

Backing Up Standard SAP Web AS Profiles and Scripts

We strongly recommend that after the installation and before you enable virtual addressing, you make copies of all standard SAP Web AS profiles and scripts. You need to have these ready for critical tasks such as the maintenance and upgrade of the SAP Web AS system, the DBMS and the operating system. You should also keep copies of some files for security reasons not related to switchover.

The files you need to back up include the following:

• startsap and stopsap scripts

• All instance profiles

• The default profile

• DB config files

• startdb

• /etc/passwd, /etc/groups, /etc/fstab and /etc/services

If standard configuration files are readily available, you can manage all critical situations using established procedures. Therefore, by keeping the standard files you help to avoid a single point of failure in your SAP Web AS system.

Installing SAP Web AS Units

You can easily install the switchable SAP Web AS service units, CI and DB, with the standard tool for SAP Web AS installations, SAPinst.

You can use SAPinst to install all required SAP Web AS instances: CI-only, DB-only, and central systems with combined CI/DB on any of the cluster nodes. You can also install additional application servers, which are called dialog instances in SAPinst.


February 2006 63

The SAPinst tool does not directly support the special configuration required for SAP Web AS in a switchover environment. Therefore, you must perform manual configuration to enable the SAP Web AS and the switchover software to work together correctly.

The following sections describe the most important differences from the standard installation procedure. However, this overview might not be complete for all switchover products. Therefore, we recommend you to contact your switchover software vendor for more information.

Installing a Central System (DB/CI)

To install the database and a central instance (DB/CI) on the same node, follow the instructions in the relevant installation guide.

Modifications on the Standby Node

1. Create the shared-disk partitions on the standby node. This step depends on your particular switchover product. For more information, see the product documentation.

2. Create the SAP-specific users and groups on the standby node, if they do not already exist. The users and groups that you need to create for the SAP Web AS and the database are described in Chapter 1 of the documentation SAP Web AS Installation on UNIX - OS Dependencies. Make sure you are using the same user and group IDs. Create the home directories of the users and copy all files from the home directory of the primary node (this might not be necessary for DB users).

3. Create all the mount points for the file systems necessary for a switchover. You do not need to create mount points that are already on the shared disks.

4. On an Oracle database, copy the file /etc/oratab from the primary node. It contains information for the ORACLE SQL*NET listener process. Remember not to overwrite any existing local file. For example, if a test system is running on the standby node, it is best to merge the /etc/oratab files.

Installing Other SAP Web AS Instances

To install additional SAP Web AS instances on other hosts, follow the instructions in the relevant installation guide. These hosts do not need to be part of the cluster. Note that application servers (AS) are called “dialog instances” in SAPinst.

We recommend you to use sapcpe to distribute SAP Web AS ABAP kernel executables to different nodes. For more information, see ABAP: Creating Local Executables (sapcpe) [Page 61].

Installing the DB and CI on Different Nodes

To install the database (DB) and central instance (CI) on several nodes, follow the instructions in the relevant installation guide. We recommend that you first install a database and central instance on one node using SAPinst and later distribute them to their dedicated host machines.

6.1.3 Adapting Scripts and Profiles

Naming Conventions for startsap and stopsap

Since SAP Web AS 6.10, the start and stop scripts are located in

/usr/sap/<SID>/SYS/exe/run/startsap

/usr/sap/<SID>/SYS/exe/run/stopsap

These scripts can be accessed by every instance. The old approach with local scripts and aliases is no longer in use. Therefore, no adjustment of start and stop scripts is required.


February 2006 64

Startup Profiles

Startup profiles can also contain local host names, both in their file names and contents. Pay attention to the following files:

• /sapmnt/<SID>/profile/<SID>_<INSTTYPE><NR>_<hostname>

• /usr/sap/<SID>/profile/START_<INSTTYPE><NR>_<hostname>

If the profiles for the CI on the normal host and the standby host do not need to be different (see below), simply leave the installation as it is and skip the information on local host names given in this section.

All of the comments in this section only apply to an installation if the host names appear in the above file names.

Again, it is our aim to keep the SAP Web AS administration on a switchover cluster as close as possible to the conventions used in standard installations. That is why you should maintain two versions of the files so that both include the corresponding local host names as follows:

• If the profiles are identical on both machines, create the standby file as a soft link. This makes maintenance easier when changes are necessary and enables identification of the original. Change the local host name in the profile name to the local host name of the standby. Profile maintenance from within the SAP Web AS system using transaction RZ10 works correctly.

• If the profiles have to be different on the normal and the standby machine (because the machines have different hardware, for example), create a copy to be read by the standby host, apply the profile changes, and change the local host name in the file name to the local host name of the standby.

Proceed in a similar way with .dbenv_<hostname> in the home directory of user <sid>adm. This file is sourced by .cshrc which dynamically calls the local host name. Generally, do the same for any file names that contain local host names.

In addition to file name changes, you have to insert the explicit local host name into the contents of the profile START_<INSTTYPE><NR>_<hostname> wherever the instance profile <SID>_<INSTTYPE><NR>_<hostname> is referenced (that is, lines with pf=...). Make sure that the host names used internally and the name of the file correspond to each other.

6.1.4 Performing the Installation for Java only Since Web AS 6.40 SR1 the SAPinst directly supports the installation of Web AS Java in a highly available manner. The installation medium contains an additionally product catalog. This facilitates an easy configuration of the Web AS Java only server in a highly available manner.

As the interaction to safeguard the SCS and the DB against failure is heavily depended on the HA platform see the HA partner documentation for detailed installation instruction. In this chapter only the basic steps to install the Web AS Java only in a HA environment are introduced.

Installing the Data Base

To install and operate the database in a highly available manner contact your HA partner and database vendor.

Installing the SCS

Start SAPinst with a virtual SCS host name variable as follows:

a. Open a command prompt and change to the relevant directory of the Installation Master DVD:

<DVD>:\IM<xx>\SAPINST\<OS>\<plattform>

b. Enter:

sapinst product_ha.catalog SAPINST_USE_HOSTNAME=<SCS_virtual_host_name> to use the virtual host name for the SCS installation.


February 2006 65

Chose SAP NetWeaver ’04 Support Release 1 → Java System → SCS Installation.

Follow the instructions given in the SAPinst dialogs and enter the required parameter values. Make sure you provide the virtual hostnames for database instance.

After installing the SCS instance it must be safeguarded against hardware and software failure. How this is accomplished depends on the HA platform and is subject of your HA partner. Detailed description is provided by the HA partner.

Installing the J2EE database (required for some data base)

Logon to the host where you want to install the Java central instance.



b. Enter:

sapinst product_ha.catalog SAPINST_USE_HOSTNAME=<database_virtual_host_name> to use the virtual database host name for the Java database installation.

c. Chose SAP NetWeaver ’04 Support Release 1 → Java System → Java Database Installation.

d. Follow the instructions in the SAPinst dialogs and enter the required parameter values. For the SCS instance host name, enter the virtual SCS host name.

Installing the Java Central Instance

Logon to the host where you want to install the Java central instance



b. Enter:

sapinst product_ha.catalog to start the Java CI installation.

c. Chose SAP NetWeaver ’04 Support Release 1 → Java System → Java Central Instance Installation.


Installing an Additional Dialog Instance

Logon to the host where you want to install the Java central instance



b. Enter:

sapinst product_ha.catalog to start the Java DI installation.

c. Chose SAP NetWeaver ’04 Support Release 1 → Java System → Dialog Instance Installation.



February 2006 66

6.2 SAP Web AS File Systems and NFS If possible, create the file systems as journaled file systems (JFS). File systems like JFS allow much quicker recovery after host machine crashes. This time can be a major part of the time required for switchover.

For more information, see the documentation SAP High Availability SAP High Availability SAP High Availability [Page 8].

6.2.1 SAP Web AS File Systems • Create the file systems or raw partitions for the database and the SAP Web AS instance on

shared disks.

• You can find the required file systems and sizes in the installation guide.

• File systems for SAP Web AS instances

Apart from the additional file systems or raw devices for the database, there are usually three file systems that need to be created for a SAP Web AS instance:

/sapmnt/<SID> /usr/sap/trans (ABAP only) /usr/sap/<SID>

While /sapmnt/<SID> and /usr/sap/trans are NFS file systems, /usr/sap/<SID> is a file system of the SAP Web AS instance that is always mounted on the instance (not NFS). Therefore, at least the first two file systems might have to be created on different physical disks than the third file system, if the central instance host is not the NFS server host.

• CI to AS switchover where an additional application server is located on the switchover target host

If the node that takes over the central instance also runs an SAP Web AS instance during normal operation, we recommend using a different approach for the /usr/sap/<SID> file system.


February 2006 67

WebAS ABAP File System

The file system /usr/sap/<SID> contains two subdirectories:

− SYS contains links to the central directory /sapmnt/<SID>.

− <INSTTYPE><NR> (name defined by the type of services and the application server number, for example DVEBMGS00), which contains data for the local SAP Web AS instance.

Only the latter directory needs to be migrated with the SAP Web AS instance during the switchover. As the SYS subdirectory contains only links that do not require any space, it can be created locally on each cluster node. Therefore, instead of /usr/sap/<SID>, create a file system /usr/sap/<SID>/<INSTTYPE><NR> with the usual <> substitutions. The file name for the CI is DVEBMGS00 in most cases. This avoids mount conflicts when switching over to a node on which a SAP Web AS instance is already running. The DVEBMGS00 directory can join the /usr/sap/<SID> tree instead of mounting on top of it.

This approach becomes more and more important when thinking of central services that have to be clustered while other instances run on the cluster hosts without being controlled by the switchover software (in order to use the resources efficiently). You have to use this approach for integrated installations of the SAP Web AS with ABAP and Java stacks.

WebAS J2EE File System

The J2EE file system layout on UNIX is quite similar to the ABAP installation. The trans directory is not needed for J2EE installation. Instead of the CI the SCS directory must be located on a shared storage.

For a UNIX installation the physical layout looks like the one showed in figure below.

<SID>

exe profile global

trans

/

export usr home <sapmnt>

<SID> trans

sap <sid>adm <SID>usr

sap

SYS

exeprofile global

dbg opt run

sapmnt

log data work

<INST>

/

export usr home <sapmnt>

<SID> trans

sap <sid>adm <SID>usr

sap

SYS

exeprofile global

dbg opt run

sapmnt

mounted

soft link

trans NFS shared file system

mount point

shared storage

primary server backup server


February 2006 68

usr

sap

<SID>

workSDM

<JCinst>

j2ee exe

cluster configtooladmin

<SCSinst>

exe work

globalexe profile

<SID>

export/

sapmnt

SYS

usr

sap

<SID>

/

SYS

NFS mount

j2ee

cluster

exe work

<Jinst>

Directory hierarchyMount pointMount point (nfs)Symbolic link

srcglobalexe profile globalexe profile

Actually the symlinks point to /sapmnt not to /export

shared storagelocal storage

node 1local storage

node 2

run optdbgrunopt dbg

sapmnt

<SID>

export

sapmnt

sapmnt

<SID>

Due to the usage of NFS mounts and symbolic links, the logical file systems looks similar to a single installation as shown in figure below.

Since Windows does not support mount points and symbolic links, the directory layout is slightly different from a standard installation. The SCS instance drive and the Java CI drive are no longer the same. Furthermore the SCS cluster group provides the sapmnt share.


February 2006 69

<SCSinst>

exe global

usr

sap

SharedDrive:

<SID>

SYS

exe profile

Share as sapmnt

work

usr

j2ee

cluster

exe workwork

cluster configtool

SDM

usr

sap

LocalDrive:

<SID>

<JCinst>

j2ee

admin

exe

local storagenode 1

local storagenode 2

shared storage

The shared storage can be owned only by one node in time. That is why the SCS cluster group must also share the \usr\sap directory as sapmnt to give CI and DI simultaneously access to the global configuration data.

6.2.2 SAP Web AS ABAP: Creating Local Executables (sapcpe) The NFS directory /sapmnt/<SID>/exe usually contains the SAP Web AS kernel executables. We recommend that you do not rely on NFS to store the executables. Instead, you should keep them accessible on all SAP Web AS instances without NFS. For the cluster machines, this usually means putting the executables onto the shared disks. Disk access is migrated during switchover. However, note that this is not NFS functionality. For additional cluster-external machines, the executables are put on locally accessible disks, for example, the internal hard disk of the workstation.

Create a local file system and copy the executables manually from the central instance to the local directory. The drawback is that an additional step in the SAP Web AS upgrade procedure is required. A better method is to use the SAP tool sapcpe.

The sapcpe tool:

• Copies executables from the central directory to the local directory when you set up the system for the first time.

− Default for the central directory: /usr/sap/<SID>/SYS/exe/ctrun

− Default for the local directory: /usr/sap/<SID>/SYS/exe/run Only the most important executables are copied. For less important programs, sapcpe sets up soft links to the executables in the central directory.

• Checks whether the local executables are up-to-date at each startup of an SAP instance that uses them.

• Checks the local executables against the central directory. It copies new executables and re-copies executables if the corresponding dates or sizes have changed.

With the sapcpe tool you no longer need distribute executables by hand after installing a new SAP Web AS Release or upgrade. To update remote systems, you only need to restart the SAP instances that run on them.

For more information on how to configure sapcpe see the online documentation [Page 9] in the SAP Web AS system. Choose:

SAP Library → SAP NetWeaver → Application Platform (SAP Web Application Server) → ABAP Technology → Client/Server Technology → Setting Up Local Executables on Unix SAP Instances.


February 2006 70

For the SAP Web AS Java, there is a startup framework where all binaries on the file system are synchronized by a bootstrap program with the binaries that are stored in the database.

6.2.3 Configuring NFS NFS is a system-wide SPOF for SAP Web AS. This documentation views NFS as an extension to the operating system. Protecting NFS and making it transparently available to SAP Web AS in switchover situations is the task of the switchover product.

You need to work out how to protect NFS and which switchover cluster nodes it runs on. Note that the NFS configuration might depend on the database system you are running. The directories ought to be available for use by the SAP Web AS system before and after any switchover action. For more information see Switchover Units [Page 20].

The following sections provide some information on how to install NFS correctly so that the SAP Web AS system can use it.

NFS Directories Relevant for the SAP Web AS

There are several SAP Web AS directories that ought to be shared between all instances of a system. In a UNIX environment these are:

• /sapmnt/<SID>/profile

Contains the different profiles, to simplify maintenance

• /sapmnt/<SID>/global

Contains log files of batch jobs, central SysLog

• /usr/sap/trans

Contains data and log files for objects transported between different SAP Web AS systems (for example, development – integration). This transport directory ought to be accessible by at least one SAP Web AS instance of each system, but preferably by all.

• /sapmnt/<SID>/exe

Contains the SAP Web AS kernel executables. These executables ought to be accessible on all SAP Web AS instances directly without having to use NFS. The best solution is to store them locally on all SAP Web AS instance hosts. For more information see ABAP: Creating Local Executables (sapcpe) [Page 69].

NFS Setup for Switchover

NFS is well suited to be protected by a switchover product. Therefore, it makes sense to install it on a cluster node. The requirements of your database system might dictate how NFS has to be set up. From a SAP Web AS point of view, two ways of configuring the NFS server on a cluster node are possible: NFS on the CI host or NFS on the DB host. In both cases the NFS clients ought to use the virtual IP address to mount NFS.

If the second node is used as an additional SAP Web AS instance during normal operation (for example, as an AS), it also needs to mount the directories named above from the primary node. When exporting the directories with their original names, you might encounter the problem of a “busy NFS mount” on the standby node.

We suggest the following workaround:

1. On the primary server, mount the disks containing the directories:

/export/usr/sap/trans

/export/sapmnt/<SID>

2. The primary server creates soft links to the directories with the original SAP names:


February 2006 71

/usr/sap/trans → /export/usr/sap/trans

/sapmnt/SID → /export/sapmnt/<SID>

Alternatively, the primary server can also mount the directories:

/export/usr/sap/trans to /usr/sap/trans

/export/sapmnt/<SID> to /sapmnt/<SID>

3. The primary server exports:



4. The standby node NFS mounts:

from virt.IP:/export/usr/sap/trans to /usr/sap/trans

from virt.IP:/export/sapmnt/<SID> to /sapmnt/<SID>

If the primary node goes down and a switchover occurs, the following happens:

• These directories on the standby node become busy: /usr/sap/trans

/sapmnt/<SID>

• The standby node mounts disks to:



• The standby node configures the virtual IP address virt.IP

• The standby node exports:



• The following directories on the standby node are accessible again:

/usr/sap/trans

/sapmnt/<SID>

6.3 SAP Web AS License

6.3.1 Standard Licensing Procedure The SAP license key includes basic information about your SAP Web AS system such as setup and underlying hardware:

• SAP Web AS system identification <SID>

• Hardware specification of the message server host

Any change to the above key parameters or the location and specification of the message service host invalidates the installed license. For example, this might happen if the particular SAP Web AS component has been switched to or installed on another host machine or if the hardware has been changed. Depending on the hardware platform and operating system, the validity of the license is affected by the <SID>, the CPU ID, the MAC address of the network adapters, and the database vendor (generally, changes of the customer key).

For the SAP Web AS ABAP, if the license becomes invalid and you need to request a new one from SAP, you can install a temporary license that is valid for about three weeks. To do so, enter the following as user <sid>adm:


February 2006 72

saplicense -temp

For the Web AS Java, you have to use the Visual Administrator Tool to maintain the licensing information.

For detailed information on administration of the licensing for the J2EE Engine, see the documentation [Page 9]:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) Java Technology in SAP Web Application Server Administration Manual Installation Information Licensing of the J2EE Engine.

Note that you can only install the temporary license if a valid normal license was previously used. This means that you cannot create additional licenses when a temporary license expires.

A license that has been installed in the usual way is normally invalidated in switchover conditions. Licensing has to be set up especially for switchover environments.

For more information on saplicence, see SAP Note 14838 or the online documentation of the SAP Web AS [Page 9]:

SAP Library SAP NetWeaver Solution Life Cycle Management SAP Licenses

6.3.2 Licensing in Switchover Environments To run your SAP Web AS system in a two-node switchover cluster, you need to order two licenses. SAP needs a confirmation from the vendor that a switchover environment is being implemented and we then provide two license keys for a production SAP Web AS system ⎯ one key for each machine.

SAP has implemented a license mechanism for transparent and easy use with switchover solutions and clustered environments.

The customer key is calculated on the basis of local information on the message server host (CI host machine). Consequently, no license problem occurs when only the DB is switched over. However, CI switchovers (CI or CI/DB switchover) do affect the licensing mechanism.

For the CI or CI/DB switchover, two licenses need to be available. You can install both in parallel.

On the different CI hosts (host machine is running the message service), you need to execute the following as user <sid>adm for every license key you obtain from SAP (command for the ABAP stack): saplicense -install

For the SAP Web AS Java, you have to use the Visual Administrator Tool to maintain the licensing information. Generally you have to follow the instructions given in the online documentation of the SAP Web AS at SAP Library SAP NetWeaver Solution Life Cycle Management SAP Licenses SAP License Keys Licensing of the SAP J2EE Engine. As already mentioned the message server maintains the licenses. That is why once you have installed the license successfully for one cluster node you must switchover the SCS group/package to the secondary node. Restart the server(s) of the Java central instance and repeat the procedure.

Afterwards, you need pay no further attention to the license when performing a CI switchover. This means you do not need to call saplicense in your switchover scripts.


February 2006 73

6.4 Additional Tasks for SAP Web AS ABAP

6.4.1 Transport Control TPPARAM contains parameter settings for the transport control program tp, which is used for exports and imports. It also includes the parameter <SID>/dbhost which is used to address the DB host.

Generally, you need to set <SID>/dbhost to the virtual host name of the DB instance as described inNetwork Configuration for SAP Web AS Switchover [page 74]. This enables the use of the transport system for the normal maintenance of ABAP programs, but still allows transparent operation in the case of a switchover.

On the other hand, we recommend returning to standard, non-virtual addressing during SAP Web AS system upgrades and critical situations. In this case <SID>/dbhost uses normal and not virtual host names.

6.4.2 Upgrading If you want to use SAP’s standard tool for SAP Web AS upgrades, R3up, you must return to a standard, non-switchover configuration of your SAP Web AS system during the upgrade. Note the following recommendations.

• After the standard SAP Web AS installation, keep copies of the standard SAP Web AS scripts and profiles, which use normal addressing and not virtual host names.

For more information see Backing Up Standard SAP Web AS Profiles and Scripts [Page 62].

• Run the SAP Web AS system with standard – not virtual – addressing during the upgrade. The upgrade situation is complex and you need to try to keep it as transparent as possible by using the fixed, standard addressing schemes.

For more information on SAP Web AS upgrade in a switchover environment, contact the vendor of your switchover software product.


February 2006 74

7 Switchover System Configuration This chapter gives an overview of network configuration techniques in a standard SAP Web AS system and then goes on to explain these in switchover systems. It describes the network configuration required for different switchover modes or network topologies and illustrates these with detailed examples. We also discuss problems that might arise with database access in switchover systems.

Contents 7.1 Network Configuration for SAP Web AS Switchover....................................................74

7.1.1 Standard SAP Web AS Network Configuration ................................................................................ 74 7.1.2 Virtual IP Address Takeover ............................................................................................................. 75 7.1.3 Network Configuration Using Virtual Identities ............................................................................... 76 7.1.4 SAP Web AS Profile Settings ........................................................................................................... 76

7.2 Network Topologies and Virtual Network Identities .....................................................77 7.2.1 Naming Conventions ........................................................................................................................ 78 7.2.2 Single-LAN Network.......................................................................................................................... 79 7.2.3 Separate CI and DB Instance in a Single-LAN Network ................................................................... 79 7.2.4 Central CI/DB System in a Single-LAN Network............................................................................... 81 7.2.5 Two-LAN Network ............................................................................................................................. 82 7.2.6 Separate CI and DB Instance in a Two-LAN Network....................................................................... 82

7.1 Network Configuration for SAP Web AS Switchover A proper network layout and, especially, a consistent network resultion configuration is the key to running the SAP Web AS system successfully in a switchover environment. However, it is recommended to think of network configuration as the critical point where the SAP Web AS and switchover products interface.

You can prevent most problems during and after switchover by correctly configuring the network resolution processes. If you set up a new system or troubleshoot an existing installation, first check whether the network configuration complies with the SAP guidelines given in this section.

The most important factors that determine the configuration of the network environment for SAP Web AS system switchover are:

• The switchover mode – identity takeover or virtual IP address takeover

• The network topology – single LAN or multiple LANs for client and server communication

7.1.1 Standard SAP Web AS Network Configuration SAP’s standard concepts and rules for SAP Web AS network setups are also generally valid for switchover environments. However, you need to make some minor modifications when implementing virtual addressing, as described inVirtual IP Address Takeover [page 75]

SAP Web AS Profiles and Network Related Parameters

Normally network related parameterization is configured and maintained in SAP Web AS profiles that are read during SAP Web AS startup. However, there are some parameters, for example for RFC, that


February 2006 75

you have to configure in database tables, as described in Appendix A: Preparations for SAP Web AS ABAP Compliance Tests [Page 104].

The SAP Web AS system reads its parameters from three profiles at startup time, with the following paths and file names (note that host names are part of the profile names):

• Default profile /usr/sap/<SID>/SYS/profile/DEFAULT.PFL

• SAP Web AS Instance profile /usr/sap/<SID>/SYS/profile/<SID>_<INSTTYPE><NR>_<hostname>

• Start profile /usr/sap/<SID>/SYS/profile/START_<INSTTYPE><NR>_<hostname>

Switchover Related Parameters in SAP Web AS Profiles

Parameters Normally Set in File Content

SAPDBHOST DEFAULT.PFL <DB hostname>

SAPGLOBALHOST (Windows platforms only)

DEFAULT.PFL <hostname of global file system>

SAPLOCALHOST <SID>_<INSTTYPE><NR>_ <local hostname>

<local hostname>

SAPLOCALHOSTFULL <SID>_<INSTTYPE><NR>_ <local hostname>

<full domain name>

rdisp/vbname DEFAULT.PFL <local hostname>_ <SID>_<NR>

rdisp/btcname DEFAULT.PFL <local hostname>_ <SID>_<NR>

rdisp/enqname DEFAULT.PFL <local hostname>_ <SID>_<NR>

rdisp/mshost DEFAULT.PFL <local hostname>

Replace terms in brackets with actual values from your system, e.g. <SID>_<INSTTYPE><NR>_<hostname> by TST_DVEBMGS23_host1. The <full domain name> is the system name used for addressing under Domain Name Service (DNS) or a local name service.

Normally, those parameters are only contained in the first two files: in the default profile, which is centralized for the entire system, and in the instance profiles, which exist for every SAP Web AS instance. Put all information that is valid at a system-wide level in the DEFAULT.PFL. Make any settings specific to a particular instance (CI/SCS, AS) in <SID>_<INSTTYPE><NR>_<hostname>.

For more information on profile-naming conventions and related settings, see Adapting Scripts and Profiles [Page 63].

7.1.2 Virtual IP Address Takeover This section discusses general aspects of using virtual network identities in a SAP Web AS switchover environment. It explains how to enable the use of virtual identities and how SAP WebAS parameters depend on the network topology. It also describes configuration guidelines for single-LAN and two-LAN network setups.

Modifications to Standard Network Setup

You only need to consider minor modifications for switchover environments using virtual network resources:

• The network name used for a SAP Web AS instance within the switchover cluster must be a virtual network name (not a physical one). Such virtual names enable the using service to switch


February 2006 76

over together to another host while remaining transparently accessible to its clients via a reliable network identity.

• Despite virtual network resources, physical machines still have physical network names that are bound to the individual network adapters, or better, to stationary IP addresses associated with the local network adapters. The network should be configured in such a way that each stationary and virtual IP address of a physical adpater in a host computer exactly matches one network name. That is, because with more than one IP address you have more than one network identity. Each identity should have its own network name even if the IP addresses belong to only one physical machine. No network name should match to two or more IP addresses.

• Network names used for SAP WebAS communication should be network names for IP addresses in the public or front-end LAN, that is, the LAN to SAP clients (see the setup examples below).

7.1.3 Network Configuration Using Virtual Identities First we look at the concept of how to use virtual identities in a SAP Web AS switchover environment before going into detail.

It should be straightforward to see which network names and IP addresses should be virtual and which should be stationary. The following rules normally apply (examples are given further below):

• Virtual names and IP addresses are used for instances and their provided services that are part of a switchover environment and move between cluster nodes.

• Stationary names and IP addresses are used for instances that are not part of a switchover solution. Services provided by such instances are normally provided by external AS instances.

For example, consider the CI and AS instances in a distributed environment. They are communicating with each other using the physical network name of their physical machines. This is set by default to <physical name>_<SID>_<NR>, where <physical name> is one of the machines physical network names. For SAP WebAS instances which are not part of a switchover environment, the local host name is adequate for addressing since it is a stationary network name as described in Fehler! Verweisquelle konnte nicht gefunden werden. [Page Fehler! Textmarke nicht definiert.]).

However, e.g., to reliably localize the CI in a switchover environment, it is generally necessary to use the virtual network identities. You can achieve this by setting the parameters listed in the table of chapter 8.1.1. The CI switchover than is transparent to the external AS instances because they can keep accessing the CI by reconnecting to the virtual hostname.

If you have adjusted SAP Web AS profiles (on all instances, CI and AS) for virtual addressing, there is no need to perform any additional changes.

7.1.4 SAP Web AS Profile Settings This is only a general overview of SAP Web AS profile settings. The settings depend on the network layout and we discuss them in more detail using specific examples further below.

For more information about changing the host name of a Web AS Java instance in addition to the profile settings, refer to SAP Note 757692.

Switchover Including the DB Service

In any setup where you plan to switch over the DB service, you should set the SAPDBHOST parameter in the file DEFAULT.PFL to a virtual network name. If it is not set in the default profile, you must remember to set it in the instance profiles of the CI and all AS instances that belong to that SAP Web AS system. This enables transparent and reliable connections to the DB after switchover.

The respective parameter for the Web AS Java is j2ee/dbhost. It is also maintained in the default profile. Make sure that you also replace the physical network name with the virtual network name of the DB for the parameter j2ee/dbadminurl.


February 2006 77

Switchover Including the CI Service

The most important point to remember here is that, if the CI host machine fails, the CI is restarted on another physical host. Since the CI instance contains the enqueue service, you might need to take action to ensure database consistency after CI restart. Make sure you have read Failure and Switchover of the CI Service (Enqueue Host Failure) [Page 21].

Using the rules given above, you can work out the required changes for the SAP Web AS profile parameters.

In the CI profiles, make the following settings:

• In the instance profile <SID>_<INSTTYPE><NR>_<network_name>, set the SAPLOCALHOST parameter to a virtual network name, depending on the setup (see below).

• In the instance profile <SID>_<INSTTYPE><NR>_<network_name>, set the SAPLOCALHOSTFULL parameter to a fully qualified virtual network name, for example, virthost.wdf.sap-ag.de if DNS is used. Otherwise set it to a virtual network name (this is the same as SAPLOCALHOST).

• For service configurations on the CI (such as rdisp/vbname), you have to set the parameters to the virtual network name of the CI itself in the local instance profile, that is, to its SAPLOCALHOST setting.

In the profiles of the attached AS instances, you have to make the following settings:

• Set the SAPDBHOST parameter to the network name where the DB service can be accessed. This can be a virtual or standard network name, depending on the type of network setup used for the database service.

• Set all network related parameters of the type rdisp/.. to the proper network names, which might be partially virtual network names if the service is provided by the CI. For instance, the parameters rdisp/enqname and rdisp/msname must be the virtual network name of the CI (SAPLOCALHOST of the CI, to make CI switchover transparent to the AS instance). The setting of the additional parameters depends on how update (vbname) and batch (btcame) services are distributed on the host machines of the SAP Web AS system.

Switchover Including the SCS Instance

The most important point to remember here is that, if the SCS host machine fails, the SCS is restarted on another host machine. Using the rules given above, you can work out the required changes for the SAP Web AS profile parameters.

In the profiles of the attached AS instances, you must make the following setting:

In the instance profile <SID>_<INSTTYPE><NR>_<network_name> set the rdisp/enqname to the virtual network name of the SCS instance.

7.2 Network Topologies and Virtual Network Identities There are a variety of different options for setting up the network for a distributed SAP Web AS system.

All networks can be classified into two groups on the basis of their topology:

• Single-LAN networks that handle both the front-end and the server network traffic

• Multiple-LAN networks that handle front-end and server traffic separately. The traffic from the presentation server (front-end, such as SAPlogon, SAPGUI) to the application server uses the front-end LAN. The traffic between application servers and from application servers to the DB instance (heavy-load, server-side communication) is re-directed through on or more server LANs.

There might be additional LANs for administrative tasks in switchover clusters. For example, there might be a LAN dedicated to transmitting heartbeat signals that are required to monitor the health


February 2006 78

of the cluster nodes. For more information, contact your hardware and switchover software vendor. This documentation only deals with a maximum of 2 LANs that are used for the transmission of data traffic related to the SAP Web AS such as DB access, logon load balancing, and GUI traffic. A heartbeat LAN might be configured additonally but will not be mentioned here.

The following table gives an overview of the recommended network setup options for the SAP Web AS together with a switchover environment (heartbeat LANs not considered):

Single LAN Network Setup (recommended)

Number of LANs Network Interface Card (NIC) Configuration

Routing

Single LAN One NIC only, one LAN with IP virtual address

Not required outing

In current switched networks, we recommend the above single-LAN approach.

In some cases, you might prefer to use the two-LAN approach shown below. We support this solution but do not recommend it as the standard solution, since the two-LAN setup is more complicated, only use it if required.

Additional Supported Network Setup

Number of LANs NIC Configuration Routing

Two dedicated LANs for front-end and server traffic

Two NICs per server machine, one or both LANs with virtual IPaddresses

Static IP routing needed on servers.

Remains constant during switchover.

Benefits of Using Recommended Approaches

Below, there is a description of the two main options for setting up a network for the SAP Web AS systems in a switchover environment, the single-LAN and two-LAN network. We strongly recommend these options.

7.2.1 Naming Conventions The following sections discuss the interaction between the network setup (layout, configuration, IP addresses, network names) and the SAP Web AS system setup (SAP Web AS profile parameters). Examples below illustrate the network setups using the following naming conventions:

• Stationary IP addresses are indicated by the prefix sip_.

• Virtual IP addresses are indicated by the prefix vip_.

• Network names that refer to stationary IP addresses (mapped via name database, DNS) are written as name_... .

• Network names that refer to a virtual IP address (mapped via name database, DNS) are written as vname_... .

• The suffix _s indicates an address or name referring to a server LAN or server NIC.

• The suffix _f indicates an address or name referring to a front-end LAN or front-end NIC. In setups with only one LAN, _f is used to show the analogy to the two-LAN setups.


February 2006 79

The symbolic names use the underscore character (‘_’) in network names. This is done to make the naming conventions clear. Do not use the underscore character when actually naming hosts because this character is often used as a field separator when parsing input file names in scripts. For example, see the startup file names.

7.2.2 Single-LAN Network If only a single LAN is used for connections between the server machines – that is, CI, DB, AS machines – and the front ends, you can easily configure virtual network identities, as follows:

• You only need one virtual IP address for the SAP WebAS instance.

• There is no need for routing.

• All SAP Web AS instances communicating with the SAP WebAS instance in the switchover solution have to use the virtual network identity. Similarly, front ends accessing the SAP Web AS instance in the switchover environment services have to use the virtual network name or IP address.

Depending on which SAP Web AS services are to be switched (CI or DB, or both), see the relevant sections below.

7.2.3 Separate CI and DB Instance in a Single-LAN Network This section describes the parameters and setup for an SAP Web AS system with the CI and DB on two separate hosts with the capability of mutual takeover, as in Scenarios SO-1 and SO-2 [Page 26].

The setup of a typical switchover cluster with a single LAN for switchover scenarios SO-1 and SO-2 is shown in the following graphic.

Single-LAN Cluster for CI or DB Switchover

Switchover Cluster

DBSAPDBHOST=vname_db_f

sip_c1_f name_c1_fvip_db_f vname_db_f

CISAPLOCALHOST=vname_ci_f

sip_c2_f name_c2_fvip_ci_f vname_ci_f

ASSAPLOCALHOST=vname_e1_f

sip_e1_f name_e1_f

Frontends

Frontend LAN

Host C1 Host C2 Host E1


February 2006 80

The LAN itself might not be a single point of failure, e.g. by using multiport NICs. For an introduction to high availability measures for networks, see BC SAP High Availability [Page 8] in the SAP Library.

We assume that the DB is running with a virtual network identity that uses the virtual network name vname_db_f. The CI is running with another virtual network identity using the virtual network name vname_ci_f and the fully qualified network name vname_ci_f.wdf.sap-ag.de. The value of vname_ci_f should be joey.The SAP system should be called PR1 and configured to contain all types of services (DVEBMGS) on the instance with number 00. Accordingly the file name <SID>_<INSTTYPE><NR>_<network_name> translates into PR1_DVEBMGS00_joey.

An external AS host with the network name name_e1_f is attached to the SAP Web AS system. It is configured to contain dialog, gateway, update (vbname), batch (btcname), and spool services (DVBGS). For more information, see Batch Service [Page 38] and Update Service [Page 37] .

In the setup illustrated by the graphic above, the Network Interface Card (NIC) on the single LAN of each network machine in the system is configured to be accessible with:

• A stationary IP address (sip_c1_f, sip_c2_f, sip_e1_f in our example)

• The corresponding network names name_<host>_f (name database, DNS). These are configured to be identical to a local network names. They are mapped to the stationary IP address of the front-end NIC via the address database.

On the cluster machines that participate in switchovers, the front-end NIC is also configured to be accessible with:

• The virtual IP address of the appropriate service (vip_ci_f and vip_db_f in our example)

• The corresponding virtual network name of the appropriate service (vname_ci_f and name_db_f in our example, mapped to the virtual IP address via the address database)

Refer to SAP Note 609603 for Web AS Java issues when using multiple NICs.

Modifications network setups:

• In a standard distributed SAP Web AS system, stationary network names are used to identify all SAP Web AS instances on the system network NICs. In the case of switchover clusters, virtual network names and virtual IP addresses are available in addition to the local network resources.

• In a switchover environment it is important that you always use the virtual network names and IP addresses (if possible) to access a particular SAP WebAS instance in the switchover solution, for example, when specifying the application server name for the CI. This enables the service to switch over to another host and still be transparently accessible to its clients.

• Standard stationary network names and IP addresses are only used for cluster-external services and host machines (that is, AS instances).

Address Parameter Settings on the CI Host

Parameter Setting File

SAPDBHOST vname_db_f DEFAULT.PFL

SAPGLOBALHOST (windows platforms only)

vname_ci_f DEFAULT.PFL

SAPLOCALHOST vname_ci_f <SID>_DVEBMGS<nr>

SAPLOCALHOSTFULL vname_ci_f.wdf.sap- <SID>_DVEBMGS<nr>


February 2006 81

ag.de

rdisp/mshost vname_ci_f DEFAULT.PFL

rdisp/enqname vname_ci_f _<SID>_<nr> DEFAULT.PFL

rdisp/vbname vname_ci_f _<SID>_<nr> <SID>_DVEBMGS<nr>

rdisp/btcname vname_ci_f _<SID>_<nr> <SID>_DVEBMGS<nr>

j2ee/dbhost vname_db_f DEFAULT.PFL

Address Parameter Settings on the AS Host (ABAP)


SAPLOCALHOST Name_e1_f <SID>_<instname>

SAPLOCALHOSTFULL Name_e1_f.<fulldomain> <SID>_<instname>

rdisp/vbname Name_e1_f _<SID>_<nr> <SID>_<instname>

rdisp/btcname Name_e1_f _<SID>_<nr> <SID>_<instname>

Address Parameter Settings on the AS Host (Java)


enque/enqname vname_scs_f <SID>_<instname>

7.2.4 Central CI/DB System in a Single-LAN Network The parameters described in the following are based on a setup where the virtual network name vname_ci_f is used for a central SAP Web AS system (that is, with combined CI/DB service), which is available under the fully qualified network name vname_cs_f.wdf.sap-ag.de. The local network name is joey and the SAP Web AS system is called PR1 and is configured to contain all types of services (DVEBMGS) on the instance number 00. Accordingly <SID>_<INSTTYPE><NR>_<network_name> translates into PR1_DVEBMGS00_joey.

For more information on profile naming conventions, see Adapting Scripts and Profiles [Page 63].

An additional AS host with the local network name name_e1_f is attached to the SAP Web AS system. It is configured to contain dialog, gateway, update (vbname), and batch (btcname) services (DVBG). For more information, see Update Service [Page 37] and Batch Service [Page 38].

Address Parameter Settings on the CI/DB Host


SAPDBHOST vname_cs_f DEFAULT.PFL

SAPGLOBALHOST (windows platforms only)

vname_ci_f DEFAULT.PFL

SAPLOCALHOST vname_cs_f <SID>_DVEBMGS<nr>

SAPLOCALHOSTFULL vname_cs_f.<fulldomain> <SID>_DVEBMGS<nr>

rdisp/mshost vname_cs_f DEFAULT.PFL

rdisp/enqname vname_cs_f _<SID>_<nr> DEFAULT.PFL

rdisp/vbname vname_cs_f _<SID>_<nr> <SID>_DVEBMGS<nr>

rdisp/btcname vname_cs_f _<SID>_<nr> <SID>_DVEBMGS<nr>


February 2006 82

Address Parameter Settings on the AS Host (Cluster External)


SAPLOCALHOST name_e1_f <SID>_<instname>

SAPLOCALHOSTFULL name_e1_f.<fulldomain> <SID>_<instname>

rdisp/vbname name_e1_f _<SID>_<nr> <SID>_<instname>

rdisp/btcname name_e1_f _<SID>_<nr> <SID>_<instname>

7.2.5 Two-LAN Network If you are using two separate LANs for the server and the front-end network and consequently two NICs per host machine, the configuration is more complex than the one described above. You need to split the network traffic between the front-end LAN and server LAN. Appropriate configuration is necessary to perform this task correctly.

For a two-LAN setup of the network, note the following:

• In a standard two-LAN network setup for a distributed SAP Web AS system (no switchover cluster), the DB host does not necessarily need a LAN adapter to connect to the front-end network. Front-end access to the DB host is normally not required in the SAP Web AS system (expcept you want to administer the DB using a DB management tool from the front-end LAN). However, this is different in switchover clusters because there might be situations where a CI (including dialog work processes) is running on the former DB host. In such cases – see Scenarios SO-1 and SO-2 [Page 26] – front-end access is required and the DB host needs to be connected to the front-end LAN with a second LAN adapter.

• Routing entries are absolutely necessary and must be configured on all the server machines running the DB and SAP WebAS instances. They have to be static and remain the same during switchover. The reason why this type of routing is so essential becomes clear when considering the problems of GUI connects and logon load balancing.

• In the setup described below, virtual network identities can be used by the front ends and the server-class communication between SAP Web AS instances.

• The two-LAN solution given below has been chosen because of its transparency, manageable level of maintenance, and simple switchover concept. Other two-LAN setups might, be possible. However, they may require dynamic routing changes during switchover. This leads to very complex setups and switchover actions that might put a production SAP system at risk when a switchover occurs. We do not recommend setup options different to the ones specified in this documentation.

When the SAP Web AS runs on a two-LAN network, you need to take the entire network environment into consideration and make sure that the setup conforms to the recommendations and guidelines given.

7.2.6 Separate CI and DB Instance in a Two-LAN Network This section describes a typical two-LAN network setup for the SAP Web AS in a switchover environment using virtual network identities. It only deals with scenarios SO-1 and SO-2 that allow both a DB or CI switchover. However, you can easily apply the guidelines for the setup to the other switchover scenarios defined.

The graphic shows the setup of a typical switchover cluster with two LANs and illustrates the Scenarios SO-1 and SO-2 [Page 26].


February 2006 83

Two-LAN Cluster for DB or CI Switchover

Switchover Cluster

DBSAPDBHOST=vname_db_f

sip_c1_f name_c1_fvip_db_f vname_db_f

CISAPLOCALHOST=vname_ci_f

sip_c2_f name_c2_fvip_ci_f vname_ci_f

ASSAPLOCALHOST=vname_e1_f

sip_e1_f name_e1_f

Frontends

Frontend LAN

sip_c1_s name_c1_svip_db_s vname_db_s

Host C1

sip_c2_s name_c2_svip_ci_s vname_ci_s

Host C2

sip_e1_s name_e1_s

Host E1

Server LAN

Routes: constantvip_db_f vip_db_svip_ci_f vip_ci_ssip_e1_f sip_e1_s

Routes: constant(same as on DB host)

Routes: constant(same as on DB host)

The LAN itself should not be a single point of failure, e.g. by using multiport NICs. For an introduction to high availability measures for networks, see BC SAP High Availability [Page 8].

Although the address setup seems complex at first, it can be easily understand if proceeded as follows:

1. Configure all commincation via the front-end NIC as if it were standalone.

2. Add routing entries on the server machines to redirect intra-server communication via the server LAN.

Setup of the Front-End LAN

The NICs on the front-end LAN are configured as if only the front-end LAN were available for network communication. On all hosts the front-end NIC is configured to be accessible with:

• A stationary IP address (sip_c1_f, sip_c2_f, sip_e1_f)

• The corresponding local network names name_<host>_f . These are the local network names mapped to the stationary IP address of the front-end NIC in the address database. The SAP WebAS instances should be configured to use these host names.

In addition, the front-end NIC on the cluster machines that participate in switchovers are configured to be accessible with:

• The virtual IP address of the appropriate service (vip_ci_f and vip_db_f in our example). Using other words, for Scenarios SO-1 and SO-2 [Page 26], the database instance does not


February 2006 84

necessarily need a separate virtual IP address on the front-end LAN (vip_db_f). Front-end access to the DB instance is not necessary for the functionality of the SAP Web AS system. However, the front-end address has been included in our example to clarify the general principle that addresses on the server and front-end LAN must be switched in parallel.

• The corresponding virtual network name of the service (vname_ci_f and vname_db_f in our example, mapped to the virtual IP address in the address database)

To clarify the modifications to the standard rules for SAP Web AS network setups, note the following:

• In a standard (that is, non-switchover) distributed SAP Web AS system, physical network names (non-switchover IP addresses) are used to identify all SAP Web AS instances in the system. In switchover clusters, virtual network names and virtual IP addresses are available in addition to the physical host names.

• To run the SAP Web AS instance in the given switchover environment it is important, to always use the virtual network names and IP addresses configured on the front-end LAN to address a particular service within that SAP Web AS instance (for example, when specifying the application server name for the CI). This enables the service to switch over to another host and remain transparently accessible to its clients.

• Cluster-external services (additonal SAP WebAS instance) must be addressed by the stationary physical network names and IP addresses that are configured on the front-end LAN.

Routing entries (see below) make sure that the server traffic is re-directed via the dedicated server LAN.

You must set the SAP Web AS profile parameters as follows:

• SAPDBHOST, in the system-wide default profile, is set to the virtual network name configured for the front-end NIC of the DB host (vname_db_f in our example). This name is used to access the DB service in the entire SAP Web AS system.

• If a switchover of the DB service is not planned, SAPDBHOST in the default profile is set to the physical network name that is mapped to the front-end LAN. Then this network name is used to access the DB service throughout the SAP Web AS system.

• In the instance profile on the CI, SAPLOCALHOST and SAPLOCALHOSTFULL are set to the virtual network name of the CI on the front-end LAN (vname_ci_f and the corresponding full domain name in our example). These settings are used to access any CI-based SAP Web AS service throughout the system.

• On the AS machines, in the instance profiles, SAPLOCALHOST and SAPLOCALHOSTFULL are set to the corresponding physical network names mapped to the front-end NIC (name_e1_f and the corresponding full domain name in our example).

Setup of the Server LAN and Server Routing

The configuration is complete now if there is only one LAN. However, to redirect the intra-server communication to the server LAN, you must configure the second NIC on the server LAN so that it can be accessed with:

• A stationary IP address, which has to be different to the front-end address (sip_c1_s, sip_c2_s, sip_e1_s in our example, the suffix _s indicates the server LAN)

• The corresponding network names for the server NIC (address database, such as DNS). This is a standard name for the AS hosts (name_e1_s in our example) and a virtual network name for the cluster hosts (vname_ci_s and vname_db_s in our example).

For the redirection to work, you have to set up routing on every physical machine of the SAP Web AS system (SAP WebAS instances and DB) as follows.

Refer to SAP Note 609603 for Web AS Java issues when using multiple NICs.


February 2006 85

The server access to the virtual IP addresses of the services must be routed to their corresponding server LAN IP addresses (vip_ci_s and vip_db_s in our example): vip_db_f → vip_db_s vip_ci_f → vip_ci_s The access to the external application server IP address (note that SAPLOCALHOST is sip_e1_f) is routed to the corresponding server LAN IP address: sip_e1_f → sip_e1_s

You only need the routing entries to other instances or the DB on a given host. The routing setup should be done consistenly and should be permament, that is, it should survive a machine reboot.

Only the routing entries can make sure that the heavy-load network traffic of the server connections is correctly re-directed through the server LAN. If you ever experience performance bottlenecks in your network connections, check whether you are still using effective routing in your SAP Web AS system. You can use the network tests given in Appendix B [Page 114] to help solve such problems.

Consider that you must always use the virtual network names and IP addresses configured on the front-end LAN to address a particular service within your SAP Web AS system. Addresses on the server LAN are only accessed indirectly via routing.

Switchover Functionality

The setup described enables the Scenarios SO-1 and SO-2 [Page 26]. The CI can be taken over by the DB host and the other way around. Both virtual IP addresses and network names of the host are transited together with the corresponding service.

If the CI is switched to the DB host, both vip_ci_f and vip_ci_s are migrated simultaneously to the corresponding NICs of the DB host. On the DB host, vip_db_f and vip_db_s remain to be configured on the front-end and server NIC respectively.

The mapping of network names vname_... to their corresponding virtual IP addresses vip_... remains constant during switchover, implying that name service setup does not need to change.

The routing entries on the server machines do not need to change either, because vip_ci_f can still be accessed via vip_ci_s and vip_db_f can still be accessed via vip_db_s. Routing for the AS machines does not change because AS services do not move.

Control Scripts for SAP Web AS Switchover

February 2006 86

8 Control Scripts for SAP Web AS Switchover This chapter lists the most important actions required to switch over a SAP Web AS system that is installed on a two-node cluster. In the example discussed below, both the CI and DB instances are installed on the same primary host and, in the event of a failure, are switched over to a standby node. This procedure corresponds to switchover scenario Scenario SO-3 [Page 26], where no AS instance runs on the standby host that remains idle until the switchover takes place.

Contents 8.1 Tools for System Health Checks...................................................................................86

8.1.1 LGTST ............................................................................................................................................... 86 8.1.2 MSPROT ............................................................................................................................................ 88 8.1.3 ENSMON............................................................................................................................................ 89 8.1.4 DPMON.............................................................................................................................................. 91

8.2 Switchover Control Scripts ...........................................................................................92 8.2.1 Starting Up on the Primary Node ..................................................................................................... 92 8.2.2 Starting Up on the Standby Node..................................................................................................... 94 8.2.3 Stopping the SAP Web AS Manually ................................................................................................ 95

8.1 Tools for System Health Checks In order to check the status of the message and the enqueue service, there are some tools that can be used on operating system level.

8.1.1 LGTST LGTST is a tool to check the message server. It is delivered with the SAP kernel.

Usage

For lgtst, you have the following parameters: tpmserv1:tlaadm 60> lgtst

Test Program for LG-Layer (SAP Login Info), Version 5, Nov 19 1998

required options

-H mshost : hostname of message server

-S msserv : service-name / number of message server

Result if Message Server is up

If the message server is running, lgtst returns a list of reachable application servers and a list of selectable login-classes with favorite application servers. Example:


February 2006 87

tpmserv1:tlaadm 70> lgtst -H tpmserv1p -S sapmsTLA

using trcfile: dev_lg

list of reachable application servers

-------------------------------------

[tpmserv2_TLA_04] [10.0.0.2] [10.0.0.2] [3204] [3204] [DIA VB BTC SPO VB2 ]

list of selectable login-classes with favorites

-----------------------------------------------

[PUBLIC] [10.0.0.2] [3204] [46C]

[SPACE] [10.0.0.2] [3204] [46C]

If the message service is up, but all application instances are down and the message service is part of a central services instance, the output is as follows: tpmserv1:tlaadm 61> lgtst -H tpmserv1p -S sapmsTLA


Result if Message Server is down

If the message server is down, there is an error message as follows: tpmserv1:tlaadm 61> lgtst -H tpmserv1p -S sapmsTLA


*****************************************************************************

*

* ERROR partner not reached (host tpmserv1p, service sapmsTLA)

*

* TIME Mon Mar 31 15:37:51 2003

* RELEASE 46D

* COMPONENT NI (network interface)

* VERSION 34

* RC -10

* MODULE niuxi.c

* LINE 1063

* DETAIL NiPConnect2

* SYSTEM CALL SO_ERROR

* ERRNO 111

* ERRNO TEXT Connection refused

* COUNTER 1

*

*****************************************************************************

As lgtst is originally not intended to be used for scripts to check the availability, there is another tool that can be used for that purposes: MSPROT.


February 2006 88

8.1.2 MSPROT MSPROT is a new program to check the message server. It connects to the message server using a TCP/IP connection and lists instances with their services that can be reached via the message server. If this list changes MSPROT changes its output.

Usage

The program is called using the SID (then referring to the default profile) or using another profile that can be specified in the command line.

Using the –l option, it displays the server list only once. tpmserv1:tlaadm 76> msprot

SAP Message Server Protocol Program, Version 1.1, Mar 21 2003

usage: msprot [ -a | -t | -l ] name=<SID> | pf=<profile>

-a display all (ip/servno)

-t display time

-l list only, like msclients

Example: tpmserv1:tlaadm 77> msprot name=TLA

SAP Message Server Protocol Program, Version 1.1, Mar 21 2003

INFO CLIENT-NAME HOST SERVICE (NET) SERVICES (SAP)

--------------------------------------------------------------------------------

LIST tpmserv2_TLA_04 10.0.0.2 3204 DIA UPD BTC SPO UP2

Usage for the Java stack

The program is called using the hostname of the SCS instance and the number of the message service (as in /etc/services).

Using the –l option, it displays the server list only once.

Example: tpmserv1:tlaadm 77> msprot mshost=tpmserv1 msserv=sapmsTPJ

Usage Within a Script

Within a script, you can use MSPROT to check whether the message service is alive. Use MSPROT with the –l option to prevents MSPROT from permanently producing a list. You can check whether the service is running (rc=0) or not (rc=-1) by using the return code.

Example: #!/bin/csh


February 2006 89

set sid=$1

/home/tlaadm/mytest/msprot -l name=$sid >& /dev/null

set rc=$status

echo "$rc"

if ($rc == 0) then echo "Message Service for system $1 seems to be up."

else echo "Message Service for system $1 seems to be down."

endif

For more information on how to obtain and use msprot, see SAP note 636938.

For more information on LGTST, MSPROT, and MSMON (not discussed here) see the documentation [Page 9]:

SAP Library SAP NetWeaver Solution Life Cycle Management System Management Tools for Monitoring the System Monitoring and Administration of the SAP Message Server

8.1.3 ENSMON ENSMON is a tool to check the functionality of the standalone enqueue server.

Usage

tpmserv1:tlaadm 54> ensmon --help

standalone enqueue server monitor

=================================

usage: ensmon [--help|-help|-h] [pf=<profile>]

[-H <hostname> [-I <serverinstance>|-S <serverservicename/serverport>]]

[<opcode>] [<parameters (depending on opcode)>]

Opcodes:

--------

1: Dummy request

Send a dummy request to the server, to check if he is alive

No parameters needed

2: Get replication information

Get information about the status and statistics of the replication

No parameters needed

3: Get a file from the enqueue server

Needs additional parameters which specify which file is requested.

Some files are predefined, but you can even specify any other filename.

Parameters: [file] -o<outfile>, where [file] can be


February 2006 90

-F<filetype> or just a filename.

Filetypes:

Enqueue Server files:

1:log file 10:dev_enqadm, 11:dev_enqlisten, 12:dev_enqrepl,

13: dev_enqsig, 14: dev_enqsrv, 15: dev_enqwork, 2<nr>: dev_enqio_<nr>

Replication Server files:

30:dev_enrepserv, 31:dev_enrepsig

Other files:

40:dev_ensmon

Please add 100 to the filetype if you want the .old file

4: Get servers performance statistics

Get performance statistics information of the enqueue server.

Needs one parameter specifying which detail level is requested.

This detail level determines two things: how detailed

is the overall server statistics and how many detailed

single processing records are transferred as well.

To check the availability of the standalone enqueue service, you can use the tool as follows: ensmon –H hostname –I instancenumber 2

Return code Meaning

0 OK.

4 WARNING: Standalone enqueue server is running, but without replication.

8 ERROR: Enqueue error.

12 ERROR: ensmon could not find the standalone enqueue server.

These return codes can be used within scripts to detect the availability of the standalone enqueue server.

Usage within a script

Example:

#!/bin/csh

set ci=$1

set nr=$2

/usr/sap/TLA/SYS/exe/run/ensmon -H $ci -I $nr 2 >& /dev/null

set rc=$status

echo "$rc"


February 2006 91

if ($rc == 0) then

echo "Enqueue Service on $ci seems to be up."

else if ($rc == 4) then

echo "Enqueue Service on $ci seems to be up, but without replication."

else

echo "Enqueue Service on $ci seems to be down."

endif

8.1.4 DPMON You can use this tool to monitor the accessibility of the SAP Dispatcher (ABAP):

"dpmon NR=<instance number> -p" check, if dispatcher is alive

"dpmon NR=<instance number> -i" returns info from the dispatcher:

Examples tpmserv1> dpmon NR=12 -p

Dispatcher is alive

tpmserv1> dpmon NR=33 -p

connection to dispatcher failed

tpmserv1> dpmon NR=12 -i

name: tpmserv1_TLA_12

path: ./disp+work

systemid: 387 (Intel x86 with Linux)

relno: 7000

patchlevel: 0

patchno: 0

intno: 20034001

pid: 21953

Usage within a script

Example:

#!/bin/csh

set nr=$1

/usr/sap/TLA/SYS/exe/run/dpmon NR=$nr -p >& /dev/null


February 2006 92

set rc=$status

echo "$rc"

if ($rc == 0) then

echo "Dispatcher of instance $nr seems to be up."

else

echo "Dispatcher of instance $nr seems to be down."

endif

8.2 Switchover Control Scripts To perform the various tasks necessary for a switchover, control scripts need to include both system and SAP-specific commands.

System commands might be required to:

• Configure the virtual IP address on the standby node (including ARP-cache refresh)

• Activate the disks on the standby node

• Mount and check the file systems

SAP-specific commands are needed to:

• Start up on the primary node

• Switch over and start up on the standby node

• Stop SAP manually

The following sections focus on the tasks that need to be executed by SAP commands.

8.2.1 Starting Up on the Primary Node

NFS

Preparations for Network File System (NFS) include:

• Export of all NFS directories

• Linking or mounting of NFS directories on the NFS server node

• Mounting of NFS directories on all NFS clients (with remote shell)

Profiles

Depending on your parameter settings, it might be necessary to adapt profiles. For instance, this avoids the two-task connect problem that occurs if the central SAP Web AS instance is running on the database node.

Database

The database system needs to be checked and started up.

• Oracle

− Check and optionally adapt the init<SID>.ora file. For example, this might be necessary when database nodes have different sizes.


February 2006 93

− Remove the sgadef file

If you want to use the original SAP startup scripts, you have to remove the file $ORACLE_HOME/dbs/sgadef<SID>.dbf. It contains pointer information to the Shared Global Area (that is, Oracle shared memory). When this file is available, you cannot start Oracle normally. Delete the file manually before starting Oracle.

− Start the database

There are several ways to do this. One is to use the following code from the startsap script: echo "\nStarting SAP R/3 $SAPSYSTEMNAME Database" | tee -a $LOGFILE_STARTDB echo "------------------------------" | tee -a $LOGFILE_STARTDB echo " Startup-Log is written to ${LOGFILE_STARTDB}" | tee -a $LOGFILE_STARTDB su - ${SAPADM} -c "startdb" 1>/dev/null 2>&1 returncode=$? case $returncode in 0) echo " Database started " | tee -a $LOGFILE_STARTDB;; 1) echo " Database started, but no valid R/3 license yet installed " | tee -a $LOGFILE_STARTDB;; *) echo " Database startup failed!" | tee -a $LOGFILE_STARTDB echo " See $LOGFILE_STARTDB for Details\n" | tee -a $LOGFILE_STARTDB exit 4 esac

Make sure there is a correct entry in the file /etc/oratab. It should contain a line like: <SID>:/oracle/<SID>:N If not, the orasrv process does not allow remote database connects. If a second database is running on the database standby node, insert an entry for each database in /etc/oratab.

• Informix

If you have set all the files correctly (see above), you do not need to adapt files during a switchover. You can use the same coding to start the database as for Oracle (there is a startdb script for Informix).

• SAP DB, DB2 UDB

See Informix.

Starting the Central Instance

Start the central SAP Web AS instance using the normal startup script startsap r3. If there is a SCS instance on the system, the instance is also started using this command.

startsap command: startsap [db|r3|j2ee|all|check] [<instance>]

Specify the instance if you have installed multiple instances of the same system on one host.

Example: startsap r3 DVEBGMS00

Other optional parameters:

check Check database and SAP instance

r3 | R3 | j2ee | J2EE Start SAP instance only

db | DB | dB | Db Start database only

jdb | JDB Start Java database only

ALL | all Start database and SAP instance


February 2006 94

Starting the Instance on Standby Node

If your standby node is also running a SAP Web AS instance, you have to mount NFS and start the SAP Web AS instance using a remote shell.

Start Other Instances

Start all other SAP Web AS instances (that is, cluster-external AS instances).

8.2.2 Starting Up on the Standby Node

Stop Test System

If AS or CI instances of another SAP Web AS system run on your standby node during normal operation, first stop them before switching over the failed system.

stopsap command: stopsap [r3|all] [<instance>]

Specify the instance if you have installed multiple instances of the same system on one host.

Example: stopsap r3 DVEBGMS00

Other optional parameters:

j2ee | J2EE | r3 | R3 Stop SAP instance only

ALL | all Stop database and SAP instance

NFS

See Starting Up on the Primary Node [Page 92].

Stop the Instance on the Standby Node

This means stopping the local SAP Web AS instance, as the switchover is imminent (that is, the script is running on the standby node).

Stop All Other Instances of the SAP Web AS System

Only if a restart is required due to enqueue service restart, make sure you have carefully considered Failure and Switchover of the CI Service (Enqueue Host Failure) [Page 21].

Profiles


Database


Start Central Instance

Start the central SAP Web AS instance using the normal startup script startsap r3.

Start Other Instances

Start all other SAP Web AS instances outside the cluster.


February 2006 95

8.2.3 Stopping the SAP Web AS Manually

Stop All SAP Web AS Instances Outside the Cluster

Stop SAP Web AS instances that are running on hosts that are not part of the cluster.

Stop the SAP Web AS Instance on the Standby Node

If the standby node is used to run an additional SAP Web AS instance, stop it.

Stop the Central Instance

Stop the local SAP Web AS instance with the stopsap script.

Unmount NFS

Unmount the NFS on all hosts that are running a SAP Web AS instance on standby hosts outside the cluster.

Stop the Database

Stop the database.

For Oracle, you have to stop the orasrv process, if file systems need to be unmounted later on.

Unmount the Local NFS

If a soft link is in use, you can skip this.

Unexport the NFS

Unexport the NFS.

Using Standalone Enqueue Server with Replication Server

February 2006 96

9 Using Standalone Enqueue Server with Replication Server The following section discusses high availability measures for the new standalone enqueue server that is part of the Web AS Java and optional for the ABAP stack.

There are still limitations on the availability of the standalone enqueue server for the ABAP stack and generally for the replication server. For more information, see SAP note 524816.

For more information on installation and configuration of the standalone enqueue service see the documentation [Page 9]:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) ABAP Technology Client/Server Technology The SAP Lock Concept Standalone Enqueue Server.

There are different enqueue and message servers required for the ABAP and Java stacks. The enqueue service for the ABAP stack does not act as enqueue service for the Java stack and vice versa.

The information is subject to change when an SAP installer becomes available.

Contents 9.1 Concept .........................................................................................................................96

9.2 Limitations ....................................................................................................................98

9.3 New Central Instance Concept (ABAP) .........................................................................98

9.4 Cluster Integration ........................................................................................................99 9.4.1 Installation (ABAP) ........................................................................................................................... 99 9.4.2 Switchover Scenario....................................................................................................................... 101 9.4.3 Control Scripts ............................................................................................................................... 102

9.5 Relevant SAP Notes ....................................................................................................103

9.1 Concept The enqueue service is a critical component of the SAP system. It administers locking using objects within SAP transactions that can be requested by applications to ensure consistency within the SAP system.

Since the lock table is held in the main memory of the enqueue server, server failure without additional backup measures results in loss of the locks held. To maintain consistency, all open transactions are rolled back after the enqueue server is restarted.

The enqueue replication service enables the lock table to be replicated on a second server, the replication server. A copy of the lock table is maintained on this server. If the enqueue service fails, a new enqueue service is started on the replication server using a failover solution (cluster, partner solution) and this replication service creates a new lock table from the copy of the lock table. This enables the enqueue service, and therefore the whole SAP component, to continue operating almost


February 2006 97

without interruption. If the enqueue service fails, transactions are no longer terminated, so that work can be continued transparently.

The solution is not platform-dependent. It can be used in the same way for both high-availability environments and normal environments (that is, without the replication server).

The hardware partners provide the cluster technology for the enqueue server and its replication server, which is required for the enqueue service to operate without interruption.

The standalone enqueue server is of benefit if you want to use both hardware and software components to ensure high availability for your SAP system. Use of the standalone enqueue server ensures that the crucial component in the system (the enqueue server with the lock table) is kept as small as possible. Therefore, you no longer have a central instance that represents a single point of failure in your system.

The standalone enqueue server provides the following benefits:

• If you use the standalone enqueue server, you can perform a “rolling kernel upgrade” on the SAP application servers. This lets you shut down all the servers one after the other and load the latest kernel patch onto each one. The system remains available throughout the entire process.

• The enqueue clients (SAP application servers) and the enqueue server communicate directly, and not via the dispatchers and the message server.

• You can implement the standalone enqueue server as part of the high availability enqueue server solution (with replication server) so that the enqueue server can no longer break down.

You can use the standalone server either alone or with a replication enqueue server as part of the scenario for a high availability enqueue server.

The multithreaded architecture of the standalone enqueue server enables enqueue request processing and synchronization with the replication server to be performed in parallel.

The I/O load, which on a conventional SAP system is dealt with sequentially by the dispatcher, is distributed across several threads. In most cases, this makes it possible to process a higher number of enqueue requests.

Failover Cluster

StandaloneEnqueue Server

EnqueueService

EnqueueTable Replication

ReplicationServer

ReplicationService

ReplicationTable

Application Servers

Dispatcher

WP WP WP


February 2006 98

9.2 Limitations With SAP Web AS 6.40, the standalone enqueue service and the replication service are available for usage for the SAP Web AS ABAP. There is currently no installation tools.

The SAP Web AS Java already uses the standalone enqueue service. However, there are no installation tools by SAP to install the replication service and integrate it into a switchover environment.

To implement a fail-over to the replication server you need to use switchover software. SAP does not provide support for the related cluster integration (which is described in general terms in this document). Contact your switchover software vendor for detailed availability and integration information.

9.3 New Central Instance Concept (ABAP) With the new standalone enqueue service, the concept of the central instance of an SAP system changes: The CI only contains enqueue and message service. This helps to get a lean instance that can be recovered quickly. This new central services (CS) do not contain any dialog work processes as the former CI. The dialog instances work independently of this new CS.

This solution has some benefits:

• The new CS is lean and can be quickly recovered.

• The nodes in the cluster can be used by other SAP instances to exploit the capabilities of the hardware.

• Rolling kernel upgrade becomes possible.

SAP System

EnqueueService

MessageService

Central Services

Dis

patc

her

WorkProcess

Dialog Instance

WorkProcessWork

ProcessWorkProcess

RDBMS


February 2006 99

9.4 Cluster Integration

9.4.1 Installation (ABAP) As the SAP Web AS Java 6.40 already contains the SCS instance with the standalone enqueue service, this section only describes how to install it for the ABAP stack.

Create a new Central Services Instance

To install the standalone enqueue service it makes sense to manually create a separate instance:

Create a separate directory /usr/sap/<SID>/ASCS<nr> with the respective directories data, log, sec, work. This directory should reside on shared disks because it has to be switched between the nodes in the cluster.

Download the executables for the standalone enqueue server from the SAP Service Marketplace and copy it to /usr/sap/<SID>/SYS/exe/run.

Create a start profile as follows (where <SID>=system ID, <nr>=instance number, <hostname_ascs>=virtual hostname of the ASCS instance): #-----------------------------------------------------------------------

SAPSYSTEMNAME =<SID>

INSTANCE_NAME =ASCS<nr>

Execute_00 =local $(DIR_EXECUTABLE)/sapmscsa -n pf=$(DIR_PROFILE)/<SID>_ASCS<nr>_<hostname_ascs>

#-----------------------------------------------------------------------

# start message server

#-----------------------------------------------------------------------

_MS =ms.sap<SID>_ASCS<nr>

Execute_01 =local rm -f $(_MS)

Execute_02 =local ln -s -f $(DIR_EXECUTABLE)/msg_server $(_MS)

Start_Program_01 =local $(_MS) pf=$(DIR_PROFILE)/ <SID>_ASCS<nr>_<hostname_ascs>

#-----------------------------------------------------------------------

# start enqueue server

#-----------------------------------------------------------------------

_EN =en.sap<SID>_ASCS<nr>

Execute_03 =local rm -f $(_EN)

Execute_04 =local ln -s -f $(DIR_EXECUTABLE)/enserver $(_EN)

Start_Program_02 =local $(_EN) pf=$(DIR_PROFILE)/ <SID>_ASCS<nr>_<hostname_ascs>

#-----------------------------------------------------------------------

# start syslog collector daemon

#-----------------------------------------------------------------------

_CO =co.sap<SID>_ASCS<nr>

Execute_05 =local rm -f $(_CO)

Execute_06 =local ln -s -f $(DIR_EXECUTABLE)/rslgcoll $(_CO)

Start_Program_03 =local $(_CO) -F pf=$(DIR_PROFILE)/ <SID>_ASCS<nr>_<hostname_ascs>


February 2006 100

#-----------------------------------------------------------------------

# start syslog send daemon

#-----------------------------------------------------------------------

_SE =se.sap<SID>_ASCS<nr>

Execute_07 =local rm -f $(_SE)

Execute_08 =local ln -s -f $(DIR_EXECUTABLE)/rslgsend $(_SE)

Start_Program_04 =local $(_SE) -F pf=$(DIR_PROFILE)/ <SID>_ASCS<nr>_<hostname_ascs>

#-----------------------------------------------------------------------

The start profile ensures that it can be used by the startsap/stopsap mechanism.

For fail-over purposes, it can make sense to create an instance where the message service and the enqueue service can be started and stopped separately. In this case, the failure of the message service does not cause a fail-over when it can simply be restarted.

Create an instance profile <SID>_ASCS<nr>_<hostname_ascs> as follows: SAPSYSTEMNAME = <SID>

SAPLOCALHOST = <hostname_ascs>

SAPLOCALHOSTFULL = <hostname_ascs>.<fulldomain>

INSTANCE_NAME = ASCS<nr>

SAPSYSTEM = <nr>

rdisp/mshost = <hostname_ascs>

enque/table_size = 4096

enque/process_location = LOCAL

enque/server/internal_replication = true

enque/server/replication = true

enque/enrep/keepalive_count = 0

# for performance tuning

enque/server/threadcount = 1

# these are needed to prevent the pools from being created

ipc/shm_psize_16 = 0




Create a New Instance for the Replication Service

In order to handle the replication server, it makes sense to create a separate instance for it:

Create a separate directory /usr/sap/<SID>/ASCS<nr> with the respective directories data, log, sec, work. This directory should reside on shared disks because it has to be switched between the nodes in the cluster.


February 2006 101

Create a start profile as follows (where <SID>=system ID, <nr>=instance number, <hostname_rep>=virtual hostname of the REP instance) (the instance number has to be different from the ASCS instance): #-----------------------------------------------------------------------

SAPSYSTEMNAME =<SID>

INSTANCE_NAME =REP<nr>

#-----------------------------------------------------------------------

# start enqueue replication server

#-----------------------------------------------------------------------

_ENR =enr.sap<SID>_REP<nr>

Execute_01 =local rm -f $(_ENR)

Execute_02 =local ln -s -f $(DIR_EXECUTABLE)/enrepserver $(_ENR)

Start_Program_01 =local $(_ENR) pf=$(DIR_PROFILE)/ <SID>_REP<nr>_<hostname_rep>

The start profile ensures that it can be used by the startsap/stopsap mechanism.

Create an instance profile <SID>_REP<nr>_<hostname_rep> as follows: SAPSYSTEMNAME = <SID>

SAPLOCALHOST = <hostname_rep>

SAPLOCALHOSTFULL = <hostname_rep>.<fulldomain>

INSTANCE_NAME = REP<nr>

SAPSYSTEM = <nr>

enque/serverhost = <hostname_ascs>

# these are needed to prevent the pools from being created





9.4.2 Switchover Scenario The following graphic shows the general switchover scenario for the standalone enqueue service and enqueue replication service. To illustrate the full functionality, the graphic shows the fail-over scenario with a 3-node cluster.

When the replication server fails, it should be restarted (on the same server or on another server in the cluster, but not on the server running the ASCS instance).

When the message server fails it has just to be restarted. When the enqueue service fails, a fail-over to the host running the replication server has to be initiated. This is required because the replication server holds the replica table that is used to rebuild the enqueue table when the enqueue service is restarted.

After the fail-over, the replication service should be started on another host (if available) to provide continued protection for the enqueue service.


February 2006 102

Cluster

ASCS

EnqueueService

MessageService

REP

ReplicationService

other

Cluster

ASCS

EnqueueService

MessageService

REP

ReplicationService

other -->REP

ReplicationService

Failover

Cluster

ASCS

EnqueueService

MessageService

REP -->ASCS

ReplicationService

other -->REP

ReplicationService

Failover

EnqueueService

MessageService

start

9.4.3 Control Scripts The following graphic shows an example for control scripts.

The “check” script runs periodically and checks the availability of the enqueue service, the replication service, and the message service. If the replication service is down, it is restarted. If the enqueue service or the message service is down, a fail-over of the ASCS instance is initiated.

The “fail-over” script contains the steps for a fail-over of the ASCS instance. First of all, the fail-over host has to be determined. This is the host where the replication server runs. The switchover software has to be able to determine this host and to perform a switchover exactly to this host. Then the ASCS instance is stopped on the local host and restarted on the remote host.

For the “start of the ASCS on the remote host” the ASCS instance is restarted on the new local host (this is the new local host after the switchover) and the REP instance is started on the new fail-over host (this might be any host within the cluster). Now the REP instance has to be stopped on the local host (only for kernel 4.6D).


February 2006 103

test enqueueservice

OK?

only REPdown?

test messageservice

- detect remote host- start REP on remote host Fail-over

Start

OK?

Stop

Fail-over

Check

Start

detect fail-over host

stop ASCS instanceon local host

start ASCS onremote host

Stop

Fail-over

Start

detect fail-over host

start ASCS instanceon local host

Stop

Start ASCS onremote host

start REP instance onremote host

stop REP instance onlocal host (only 4.6D)

9.5 Relevant SAP Notes Relevant SAP Notes

Note number Topic

524816 Standalone enqueue server

597024 Enqueue log, sequence of operations not guaranteed

569996 High availability and automation solution for DB2 on z/OS

Appendix A: Preparations for SAP Web AS ABAP Compliance Tests

February 2006 104

10 Appendix A: Preparations for SAP Web AS ABAP Compliance Tests We have designed a test procedure to determine whether the switchover products of vendors fully support the SAP Web AS system. The procedure includes a series of extensive SAP Web AS functionality tests that you need to perform repeatedly. This appendix describes exactly how to prepare your system for the tests.

You must prepare the system carefully according to the instructions given here, so that the tests can supply meaningful results to indicate whether the switchover software setup complies with the SAP Web AS system.

See Appendix B: SAP Web AS ABAP Compliance Tests [Page 114] for a description of the overall test procedure and step-by-step instructions on how to perform the SAP Web AS functionality tests.

Contents 10.1 Requirements for the Test Environment...................................................................104

10.1.1 Hardware ....................................................................................................................................... 104 10.1.2 SAP Web AS System Setup .......................................................................................................... 105

10.2 Preparing the Tests ...................................................................................................105 10.2.1 Setting Up Logon Groups – Transaction SMLG ........................................................................... 105 10.2.2 Setting Up Operation Modes – Transaction SRZL........................................................................ 107 10.2.3 Setting Up a Remote RFC Destination – Transaction SM59......................................................... 108 10.2.4 Creating Time-Periodic Batch Jobs – Transaction SM36............................................................. 109 10.2.5 Creating Event-Periodic Batch Jobs – Transaction SM36 ........................................................... 110 10.2.6 Setting Up a Printer (SPAD).......................................................................................................... 112 10.2.7 Setting Up the Internet Control Framework ................................................................................. 113

10.1 Requirements for the Test Environment

10.1.1 Hardware Before testing make sure that:

• The host machines and the cluster (that is, number of hosts) meet the minimum sizing requirements. For more information, see Hardware Requirements [Page 25].

• A printer is available to test the spool service. The printer must not be connected directly to the machine where the spool work process is running (CI) because obviously the printer cannot then be accessible after the CI host machine has failed and a CI switchover has occurred. Connect the printer to an external host.

For more information see the SAP documentation SAP High Availability SAP High Availability [Page 8].


February 2006 105

10.1.2 SAP Web AS System Setup Before you test the switchover software for compliance with the SAP Web AS, you need to prepare the system appropriately. The following describes the standard setup, which is a prerequisite for the SAP Web AS switchover compliance tests.

To prepare the standard set up for SAP Web AS compliance tests:

• Set up a single-LAN network as specified in Single-LAN Network [page 79].

• Install and set up CI, DB, and AS instances on machines appropriate for the chosen switchover scenario.

• Install all critical components (that is, message and enqueue services) and the additional SAP Web AS services (dialog, batch, update, spool, and gateway) on the CI host.

• Configure the cluster-external AS host as a dialog instance only.

• Include another SAP Web AS system, in addition to the switchover system, to check RFCs from external systems.

• Do not configure or turn on DB Reconnect. The DB Reconnect functionality is not included in the compliance tests for switchover software.

You might want to set up your environment differently, for example, with update and batch services distributed over several machines. To avoid a single point of failure, locate critical services on the CI.

Although DB Reconnect is not tested in the switchover software tests, we recommend that it be used as one of the major high availability features of the SAP Web AS system.

10.2 Preparing the Tests To be able to run the SAP Web AS functionality tests with the switchover product, you have to correctly prepare the system before starting the tests:

• Set up logon groups

• Set up operation modes

• Set up the RFC destination of the switchover system on a remote SAP Web AS system

• Schedule time-periodic jobs

• Create user events

• Schedule event-periodic jobs

The following sections describe the steps necessary to perform these tasks.

10.2.1 Setting Up Logon Groups – Transaction SMLG To enable a logon load-balancing check, you need to set up a logon group that includes all the SAP Web AS instances running dialog services. Follow the steps in the order given to set up a logon group for the switchover environment.

Setting Up a Logon Group

Step What to Do

1 To make sure that the message service of the specified system can be accessed correctly, enter the following in the services file of your front-end PC or UNIX machine:

sapms<SID> <ms_port>/tcp

where <ms_port> is the port number that packages are directed to by the TCP network layer.


February 2006 106

According to standard SAP conventions, the message service of an instance with the system number <NR> = 00 is accessible on port 3600. All further system numbers access port numbers higher than 3600. For example, <NR>=01 maps to port 3601, and so on.

2 Log on to your SAP Web AS system.

3 Start transaction SMLG to display the application server names of all active SAP Web AS instances that are running the dialog service. If virtual addresses are used, the appropriate application server names must contain virtual addresses.

If standard addresses are used, stationary host names should appear.

4 Double-click on the CI entry.

The Create/Change Entry window appears.

Enter a <groupname>. This must be the logon group for the system <SID>.

Choose Enter.

5 Double-click on the CI entry again.

The Create/Change Entry window reappears.

Choose the button with the arrow icon.

Enter the name of the logon group <groupname> in the dialog box that appears (as in step 4 above).

Enter 1 in Load Limits in the User field. This makes the load-balancing program choose another instance as soon as one user has logged on. Note that the optimal server is recalculated on this basis every 5 minutes.

Choose Copy.


February 2006 107

Step What to Do

6 Perform the following steps for all listed instances:

Double-click on an entry without group assignment.

The Create/Change Entry window reappears.

Insert the same group <groupname> as above.

Choose the button with the arrow icon.

In the dialog box that appears, enter the logon group name <groupname> (as in step 4 above).

Enter 1 in Load Limits in the field User. This makes the load balancing program switch to another instance as soon as one user has logged on.

Choose Copy.

When you have finished, all instances that appear in the list should have the same logon group.

7 Choose Save and Back.

8

Go to your front-end machine and set up a logon group with the specified name <groupname> as usual.

10.2.2 Setting Up Operation Modes – Transaction SRZL

Operation Modes

Step What to Do

1 Log on to the SAP Web AS system.

2 Call transaction RZ04 to maintain operation modes.

3 Choose Operation Mode → Create from the menu to create an operation mode.

4 Enter an Operation mode name and a Description (for example, Daytime) and save.

5 Create a second operation mode (for example, Nighttime) as described above.

6 Maintain the instances for an operation mode by placing the cursor on the mode and choosing Instances/OP modes.

7 In the next screen choose Instance → Create new instance.

8 Enter the name of the host on which the SAP Web AS instance is running.

Choose the CI host for the tests.

You have to enter the virtual host name, if the CI is using it. This ought to make sure that the SAP Web AS instance is still defined correctly after a switchover.


February 2006 108

Step What to Do

9 You can choose a different number of work processes for one instance in each operation mode:

Double-click on the operation mode of an instance in the CCMS screen Maintain Operation Modes and Instances.

Change the number of work processes with the available buttons.

10 After defining all instances correctly (see also the online documentation), maintain the timetable for operation modes.

11 Call transaction SM63 and choose Change on the initial screen.

12 Mark the desired interval and assign an operation mode. Make sure you change the operation mode during the day so that you can test automatic changes of the mode.

10.2.3 Setting Up a Remote RFC Destination – Transaction SM59 Apart from the RFC destinations used within one SAP Web AS system, there are also destinations used for connections between different SAP systems. For example, these might be required for remote comparisons of table entries. To try out an R/3 RFC to your test system from a different SAP system, your switchover system has to be defined as a remote RFC destination on a second SAP system. Transaction SM59 is used to maintain RFC destinations.

Setting Up a Remote RFC Destination

Step What to Do

1 Log on to a networked, but different SAP system, that is, not to the switchover system that you intend to test.

2 Call transaction SM59 for maintaining RFC destinations.

3 Choose Create to define a destination.

4 In the RFC-Destination field, enter the <SID> of your SAP Web AS switchover system.

In the Connection type field, enter 3.

Choose Enter.

Additional entry fields appear.

5 In the Target machine field, enter the host name of the CI node of the SAP Web AS switchover system you are testing:

• If virtual addressing is used, enter a virtual host name.

• If standard addressing is used, enter the local host name of the CI.

In the System number field, enter the SAP system number.

In the Description field, briefly characterize the destination

6 Save the destination. Log off from the remote SAP system.


February 2006 109

10.2.4 Creating Time-Periodic Batch Jobs – Transaction SM36 To prepare for the tests of the batch job system, you need to create the following types of time-periodic batch jobs:

• A job that runs on an instance dynamically assigned at runtime. No target host is specified in advance. This job runs on any instance with a free work process.

• A job that runs on a target host specified in advance.

Batch jobs are created with transaction SM36.

Creating a Job Without Specifying a Target Host

Step What to Do


2 Call transaction SM36.

3 In the Job name field, enter: SO TPERIODIC NOTARGET

In the Job Class field, set A, B, or C. Do not enter a target host.

4 Choose Steps.

Choose ABAP and enter the name of the program that will run during the batch job (for example, RSICC000 as a dummy report).

5 Choose Save and go back.

6 Choose Start date and select a start time and date.

7 Select Immediate and Periodic Job.

8 Choose Period values and enter the time interval for the execution of the job.

Choose Other period and enter a short interval (for example, 5 minutes).

9 Choose Save 3 times.

This saves the settings for the start time and takes you back to the entry screen of transaction SM36.

10 Save the first job.

Note that you do not enter a target host for this test setup.

Creating a Job Specifying the CI as Target Host

Step What to Do




February 2006 110

Step What to Do

3 In the Jobname field, enter SO TPERIODIC CIHOST

In the Job class field, set A, B, or C. Again, do not enter a target host.

4 Choose Steps. On the following screen choose ABAP and enter the program that will run during the batch job (for example, RSICC000 as a dummy report).


6 Choose Start date to select a start time and date.

7 Select Immediate and Periodic Job.

8 Choose Period values and enter the time interval for the execution of the job. Choose Other period and enter a short interval (for example, 5 minutes).

9 Choose Save 3 times.

This saves the start time settings and takes you back to the entry screen of transaction SM36.

10 Choose F4 on the Target host field and select the CI host from the list.

This schedules the job to run on the CI.

If virtual addressing is used on the cluster, the CI name that appears must contain a virtual host name.

11 Save the second job. This job is assigned to run on the CI host.

10.2.5 Creating Event-Periodic Batch Jobs – Transaction SM36 In addition to the time-periodic batch jobs created above, you also have to create two event-periodic jobs:

• A job to run on an instance dynamically assigned at runtime. No target host is specified in advance. This job runs on any host with a free work process.

• A job to run on a target host specified in advance.

The following explains the steps necessary to create the event-periodic batch jobs. Before the jobs can be created, you have to define the events to trigger the jobs.

Defining User Events (SM62)

Two events are required, one to initiate the event-periodic batch job with free instance assignment, and the other to initiate the job dedicated to run on the CI.

Creating Events

Step What to Do

1 Call transaction SM62

2 In User event names select Maintain and choose enter.


February 2006 111

Step What to Do

3 Choose Create.

4 Enter the EventID SO EVENT NOTARGET and an Event description.

5 Save your entries.

6 Choose Create.

7 Enter the EventID SO EVENT CIHOST and an Event description.

8 Save your entries.

Creating an Event-periodic Job Without Specifying a Target Host

Step What to Do


2 In the Job name field, enter SO EPERIODIC NOTARGET

In the Job class field, enter A, B, or C. Do not enter a target host.

3 Choose Steps.

A new screen appears.

Choose ABAP and enter the program to run during the batch job (for example, RSICC000 as a dummy report).


5 Choose Start date and select After event.

Enter the name of the event or select the event from the returned list with F4.

In the Event field, enter: SO EVENT NOTARGET

Select Periodic Job (event-periodic).

6 Save the settings and return to the entry screen of transaction SM36.

Save the batch job.

Creating an Event-Periodic Job Specifying the CI as Target Host

Step What to Do

1 Call transaction SM36


February 2006 112

2 In the Job name field, enter: SO EPERIODIC CIHOST

In the Job class field, set A, B, or C. Do not enter a target host.

3 Choose Steps.

A new screen appears.

Choose ABAP and enter the program to run during the batch job (for example, RSICC000 as a dummy report).


5 Choose Start date and select After event.

For Event enter: SO EVENT CIHOST

Select Periodic job (event-periodic).

6 To schedule the job to run on the CI host, choose F4 for the Target host field and select the CI from the list that appears.

If virtual addressing is used on the cluster, the CI name that appears on the list must contain a virtual host name.

7 Save the settings and return to the entry screen of transaction SM36.

Save the batch job.

10.2.6 Setting Up a Printer (SPAD) To be able to test the spool system, you have to set up a printer. The printer should be connected to an external machine that always remains accessible to the printer server with a constant network address.

Setting Up a Printer

Step What to Do


2 Call transaction SPAD.

3 Select Output devices and choose Change.

4 Select Create to define a printer.


February 2006 113

Step What to Do

5 Enter the name of your printer in Output Device name and select the appropriate Device type.

Choose the Spooler server name as follows:

For Releases prior to 2.2F, use the stationary host name.

For Releases 2.2F and later you can use virtual application server names.

• If virtual addressing is used for the CI, use the virtual host name of the spool service machine (CI) for this parameter. Normally the settings offered by F4 give you the virtual name. This makes sure that spooling is still available after the switchover.

• Host printer is the name of the printer as configured at the OS level. The Access method can be L or N for locally defined printers (local to the spool WP) or U or S for remote printers (via Berkeley or SAP-protocol).

6 Save your printer definition and go back to the list of printers.

10.2.7 Setting Up the Internet Control Framework To be able to test the Internet Control Framework (ICM) and the function of the ICM, you have to set it up.

Setting Up the ICF

Step What to Do


2 Call transaction SMICM.

3 Select Goto and choose Parameters - Display.

4 Check if the following parameters have been set:

icm/plugin_<xx>

icm/server_port_<xx>

There has to be a plugin_<xx> parameter specifying http and a respective server_port_<xx> parameter specifying the http port.

Appendix B: SAP Web AS ABAP Compliance Tests

February 2006 114

11 Appendix B: SAP Web AS ABAP Compliance Tests This appendix describes the test procedure that we recommend for all vendors who want to offer switchover products for an R/3 environment. The overall test procedure includes a number of SAP Web AS functionality tests that you have to perform:

• Once before the switchover

• Once after the switchover

• Once after the switchback

The following sections give step-by-step instructions on how to perform the functionality tests. We only examine Basis functions, not business transactions, but these should function normally as in the standard SAP Web AS system.

Before you begin the functionality tests, it is important to prepare your system as described in Appendix A: Preparations for SAP Web AS ABAP Compliance Tests [Page 104].

Contents 11.1 Overall Test Procedure .............................................................................................115

11.2 SAP Web AS Functionality Tests ..............................................................................115 11.2.1 Instance Processes ...................................................................................................................... 115 11.2.2 Network Functionality and Configuration .................................................................................... 116 11.2.3 Basic Network Functions and Configuration ............................................................................... 117 11.2.4 LAN Connections .......................................................................................................................... 117 11.2.5 Message Service List of Application Servers............................................................................... 120 11.2.6 Direct Front-End Logon ................................................................................................................ 121 11.2.7 Load-Balanced Group Logon........................................................................................................ 123 11.2.8 Local Gateway Addresses ............................................................................................................ 124 11.2.9 Initial SAP Web AS System Consistency – Transaction SICK ..................................................... 125 11.2.10 Message and Gateway Server – Transaction SM51.................................................................... 125 11.2.11 Logical RFC Destinations – Transaction SM59 .......................................................................... 126 11.2.12 System-Wide RFC Connections – Transaction AL08 ................................................................. 127 11.2.13 External RFC Connection to SAP Web AS Switchover System ................................................. 127 11.2.14 External RFC to SAP Web AS Switchover System at Operating System Level ......................... 128 11.2.15 Enqueue and Update Services – Transaction SM12................................................................... 128 11.2.16 Enqueue and Update Services – Program RSENQTS1............................................................... 129 11.2.17 Enqueue and Update Services – Program RSENQTSA .............................................................. 130 11.2.18 Update Service – Program VBTST300 ........................................................................................ 131 11.2.19 Time-Periodic Batch Jobs – Transaction SM37.......................................................................... 131 11.2.20 Event-Periodic Batch Jobs – Transaction SM37 ........................................................................ 132 11.2.21 Spool Service – Transactions SPAD and SP01 .......................................................................... 133


February 2006 115

11.2.22 SysLog – Transaction SM21 ....................................................................................................... 134 11.2.23 Dump analysis – Transaction ST22 ............................................................................................ 135 11.2.24 Update Records – Transaction SM13 ......................................................................................... 135 11.2.25 Transport System - Transaction SE01 ........................................................................................ 135 11.2.26 Internet Control Framework........................................................................................................ 136

11.1 Overall Test Procedure When the test environment has been set up and the tests have been prepared as described in Appendix A: Preparations for SAP Web AS ABAP Compliance Tests [Page 104], you can begin with the actual testing procedure. For each chosen scenario, you have to complete the following procedure to test all the switchover functions provided for the SAP Web AS:

1. Start the SAP Web AS system under the control of the switchover product.

2. Run the SAP Web AS functionality tests (see below).

3. Perform the switchover as specified for the scenario.


5. Perform a switchback, that is, re-establish the setup of the initial scenario.


7. Shut down the SAP Web AS system under the control of the switchover product.

We recommend you to record the following information when you run the tests:

• Technical details of the test setup (hardware, network setup, and SAP Web AS setup)

• Execution of the tests, noted on a test sheet

• Reports on problems that occurred (these should be sent to SAP)

• Test logs (for example, SAP Web AS SysLog, DB logs, OS logs)

11.2 SAP Web AS Functionality Tests The tests check whether important SAP Web AS functions work correctly with the switchover software. You have to repeat them several times as specified in the description of the test procedure above.

11.2.1 Instance Processes This is a quick test that checks the status of an SAP Web AS instance by making sure that SAP Web AS processes are running.

Checking the Status of an Instance

Step What To Do What Should Happen

1 Log on to the SAP Web AS instance host at the operating system level as user <sid>adm.

2 Enter the command: ps -ef | grep dw.sap

The output shows several dw.sap processes.

If the above test fails, the SAP Web AS is not running correctly on this instance. If so, look at the startsap log file in the home directory of user <SID>adm. It might also help to look at the developer trace files, which are located in: /usr/sap/SID/<INST><NR>/work


February 2006 116

The files start with dev.

11.2.2 Network Functionality and Configuration Correct network addressing is an essential prerequisite for running the SAP Web AS system in a switchover environment. Therefore, testing the SAP Web AS network connections is of fundamental importance and one of the primary tasks of switchover software tests. The tests here assume that you have set up your network as described in Fehler! Verweisquelle konnte nicht gefunden werden. [Page Fehler! Textmarke nicht definiert.]. The setup is a prerequisite for running the tests successfully.

The network tests use SAP’s niping tool, which is a standalone process. It uses the SAP-specific network interface that lies above TCP/IP. The SAP interface is also referred to as the network interface layer (NI). You can use the tool to reliably test the R/3 network connections between host machines. If testing already fails at the niping level, you cannot continue because this indicates that the network setup is not functioning correctly.

The tool provides an option to function as a client/server pair running independently of the SAP Web AS. The client/server test works as follows:

• The niping server is started on the target host of the connection.

• The niping client accesses the niping server by specifying a network host name.

• The niping client can be initiated to perform a loop that gives you time to check whether the server and the client side of the connection are both actually using the correct LAN interfaces. This check is possible on either the niping server or client host. The network host names (mapped to IP addresses via the name service) are used to identify the connected interfaces.

To access help, enter niping without specifying any additional parameters. You get the following information:

Test Program for NI-Layer (network interface), Version 24, Feb 27 1996

running modes start server niping -s start client niping -c self test niping -t

additional options -H hostname name of server-host (default localhost) -S service service-name or port-number (default 3298) -B bufsize size of data-buffer (default 1000) -L loops number of loops (default 10) -T tracelev trace level (0 - 3) (default 1) -F tracefile name of trace file (default stdout) -I idle time maximum idle time (default 300 sec) t > 0 shutdown after t secs idle t = 0 no automatic shutdown t < 0 shutdown after -t secs idle or first client disconnect (server only)

expert options -N timeout for completion of fragmented packages (default 100 msecs) -O one way mode -D delay delay between sends (default 0 msec) -X sec level data protection level (0 = disabled) (default 0) -Y sec id own id (server), peer (client) (default s:sample@<host>)

Check network connection between host A and B on NI-level ---------------------------------------------------------

Start niping as a server (option -s) on host A. Then start niping as a client (option -c) on host B.

The client sends <loops> packets of size <bufsize> which are echoed by the server. The client then displays the average, maximum and minimum round trip time.

Check the basic functionality of the NI-layer ---------------------------------------------


February 2006 117

To perform a self test on the local host start niping with option -t. The last line of the output should contain "*** SELFTEST O.K. ***" if no problems occurred.

Note that niping server and niping client are processes that are used to test network connections. Do not confuse these terms with “server LAN” and “front-end LAN,” which refer to two different physical networks. If you have only one LAN, both terms identify the same physical hardware, but it still makes sense to distinguish between the two. There are differences in the communication mechanisms. In addition, the network load handled by the server LAN for database communication is far greater than that handled by the front-end LAN.

Another useful test for correct naming is the transaction SM51. There you can check the correct names of the SAP Web AS instances.

11.2.3 Basic Network Functions and Configuration This test checks the basic functionality of the network software and the proper setup locally, on all host machines that are part of the system. This includes the cluster and all attached machines.

Testing the Basic Network Functionality and Configuration


1 Log on to all nodes operating in the system at the OS level as user <sid>adm.

2 On all nodes issue the command niping -t

The last line of the niping output must be Selftest O.K.

If this basic test fails, analyze the error messages issued by niping. Your network might be configured incorrectly or the network software might be corrupt so that it cannot be used by the SAP Web AS.

11.2.4 LAN Connections This test checks the network connections that use the LAN interfaces as specified in SAPLOCALHOST and SAPDBHOST.

The following describes the checks necessary for the front-end LAN connections and front-end access to the SAP Web AS system.

The test looks at the following:

• Host connections for network traffic

• Functions of the network software

• NIC configuration

• Name service

• Appropriate settings for the SAP profile parameters SAPLOCALHOST and SAPDBHOST

When you run the test, check all possible combinations. You must prove that every possible instance can act successfully both as a niping client and niping server. You must check all the following host combinations:

• CI host to DB and all AS hosts

• DB host to CI and all AS hosts

• All AS hosts to CI and DB hosts

In a test environment there might be up to two AS instances, as described in the scenario definitions for SO-3, SO-4, SO-5. For more information, see Definition [Page 24]. In the following matrix, which helps you visualize all test combinations, the application servers are referred to as AS1 and AS2. While running the tests, fill in the blank fields in the matrix when a check has been completed successfully.


February 2006 118

CI DB

CI

AS1

DB

AS2

client host

AS1

AS2

serv

er h

ost

If you are running a central CI/DB system with an external AS instance, the CI is never separate from the DB instance. In this case, you can reduce testing to the combinations:

• CI/DB host to all AS hosts

• All AS host to CI/DB host

The corresponding check matrix looks like this:

CI/DB AS1

CI/DB

AS2

AS1

client host

AS2

serv

er h

ost

Use the test matrix, when you go through the following test procedure.

Testing LAN Connections


1 Choose an SAP Web AS instance type from the first column of the matrix. The corresponding host machine <server_name> is the niping server host. Log on to this host machine at the operating system level as user <sid>adm.

2 On the niping server host <server_name> run niping in server (-s) mode with the command: niping –s

The following appears:

<date and time> ready for connect from client

The niping tool (in server mode), waits for


February 2006 119

incoming client requests. The server shuts down if idle for more than 300 seconds.

3 Choose a SAP Web AS instance type from the matrix headings. The corresponding host machine <client_name> is the niping client host.

Log on to this host machine as user <sid>adm.

4 On the nipping client host <client_name> run niping in client (-c) mode by entering: niping -c -H <server_name> -L2 -D 30000

Then quickly, within 60 seconds, proceed with step 5 to check the connection.

For <server_name> in the -H option you have to test:

• The stationary hostname of the specified server host. This is the network name that maps to the stationary IP address.

• The virtual host name of the specified server host, if virtual addressing is used. This is the network name that maps to the virtual IP address.

To run this test correctly, the <server_name> argument for the -H option above must be identical to the names configured in the SAP parameter settings:

• If the niping server is running on the CI or AS, use the name configured in their local instance profile as SAPLOCALHOST. If SAPLOCALHOST is not set on an AS instance, use the local hostname of this machine.

• If the niping server is running on the DB host, use the name configured as SAPDBHOST. This is normally set in the system-wide default profile.

Depending on the type of switchover technology chosen, you must use different kinds of host names:

• For products with identity takeover you must use standard, stationary host names.

• For products with virtual IP address switchover you must use the virtual host names.

Cluster-external AS instances are always addressed by stationary host names.

The niping client responds with:

<date and time> connect to server o.k.

The niping server responds with: <date and time> connect from host <client_name> o.k.

The niping client accesses the niping server with the network name <server hostname>.The client performs 2 loops (-L option) with a delay of approx. 30 seconds (-D option, time given in milliseconds).

Looping gives you 60 seconds to perform the check described in step 5. You can extend the time if necessary.


February 2006 120

5 While the client is still connected to the server and is looping, execute the following command on the niping server host: netstat -t | grep sapdp98

The following pair for the niping connection between client and server appears.: <client_name>.<port> <server_name>.<port> The host names are networking names that specify the interface that is being used via the name service.

By default, niping uses the service port number sapdp98 (3298) on the server host.

6 On the niping server host, check the netstat list. The connection must be established using the LAN interfaces that correspond to the setup. Check the network host names on both sides.

According to the network setup specified in this documentation, this name must always be the local host name of the specified machine (system call host name, standard host name.)

Also, check that no further routing entries are in effect to access the LAN.

7 To test all possible client hosts, repeat the procedure from step 3 onwards.

8 To test all possible server hosts, repeat the entire procedure from step 1 onwards.

9 Check all niping client/server combinations remaining in the matrix.

Depending on the type of switchover scenario you are using, also do the following:

• SO-1 and SO-2 scenarios If the CI and DB are usually located on two host machines during normal operation, they are addressed using two different network names or addresses, for example ci and db. After a switchover in scenarios SO-1 and SO-2, they are both on a single host. However the two names for accessing the services are still available. Consequently you must check both connections using the original names, even though they are running on a single machine. In the above example you need to check both ci and db.

• SO-3 scenario If, during normal operation, the CI and DB are always located on a single host, they are addressed using a single network name, for example, cidb. In this case, you only need check a single connection to the central system. In the example this is the network name cidb.

Make sure that the test setup and the results comply with the network setup specified in Network Configuration for SAP Web AS Switchover [page 74].

11.2.5 Message Service List of Application Servers The message service on the CI keeps a list of application servers that can be reached within the system. The list is important for the logon load-balancing procedure. In the following test you use the lgtst tool to access and check the message service list.


February 2006 121

Checking Reachable Application Servers


1 Log on to any of the SAP Web AS instance host machines at the OS system level as user <sid>adm.

2 Call the message service on the CI instance using the lgtst tool: lgtst -H <CI_name> -S sapms<SID>

where <CI_name> is any network name used to access the central instance (CI) service andsapms<SID> is the service name used by the message server

The output is as follows

list of reachable application servers ----------------------------------------------------- [<appservname1>] [<hostname1>] [<IP1>] .... [<appservname2>] [<hostname2>] [<IP2>] ... ...

The list shows the SAP Web AS instances known to the message server. The favorite instance for each logon group is also listed.

3 Check whether the list displayed is complete. All instances running in the entire SAP Web AS system that offer dialog services must appear in it.

4 Check the name types displayed, that is, whether they are virtual or stationary (column 1) application server (column 2) host name type (column 3) IP address

• If the system only uses stationary IP addressing: Application server names, host names, and IP addresses must be stationary. All of them must be accessible from the front-end LAN.

• If the system uses virtual IP addressing: On the cluster machines, the application server names, host names and IP addresses must be the virtual ones that are configured on the front-end LAN. The instances external to the cluster must show the stationary host names configured on the front-end LAN.

5 Check the host name part of all the application server names. These must be accessible from the front-end LAN when you log on directly from the front end without choosing a logon group.

11.2.6 Direct Front-End Logon This test checks whether front ends can connect directly to an explicitly specified instance of the SAP Web AS system. If several LANs are used, you have to check whether the front-end LAN can be used and is actually used for the connection.

During the test, a connection is established from the SAP GUI of a front-end machine to all instances running dialog work processes (that is, CI and AS). The front-end machine can be a PC or UNIX workstation on the front-end LAN.

Checking the Direct Front-End Logon



February 2006 122

1 Log on to a front-end machine and call the SAP GUI using the command required for your platform:

Windows NT workstation: sapgui <hostname> <NR>

UNIX workstation: sapgui <hostname> nr=<NR>

where: <NR> is the SAP Web AS instance number, for example 00.

Check the connect for all possible <hostname> entries that can be used to address the front-end LAN card of the specified instance. All of the following options for <hostname> must be tested, in so far as they are applicable in the given setup:

• The local host name of the specified machine. This must be configured on the front-end LAN as described in this documentation.

• Any further stationary host names mapped to stationary IP addresses on the front-end LAN

• Virtual host names mapped to virtual IP addresses on the front-end LAN

The logon screen appears.

2 In the SAP Web AS logon screen enter the client, username, password, and language. Choose Enter.

If your input is correct, a copyright popup appears. When you choose Enter, the popup disappears and the SAP Web AS user main menu appears.

3 At the operating system level, log on as user <sid>adm to the SAP Web AS instance host that you specified in step 1 above.

4 Execute the command: netstat -t | grep sapdp

The <hostname>.<port> for the connection between the SAP GUI and the SAP Web AS instance (dispatcher) is displayed.

5 Check the host names in the netstat list to make sure that the front end is connected via the network adapter configured for front-end connects.

Also, check that no further routing entries are in effect on the front-end LAN.

6 Repeat the above procedure and SAP Web AS by logging on for all SAP Web AS instances in the system offering the dialog service. Normally these are the CI and all AS instances.


February 2006 123

11.2.7 Load-Balanced Group Logon This test checks whether the load-balanced front-end logon is working correctly. Before you begin the test, you must have successfully completed the message server test. The load-balancing mechanism uses the list of reachable application servers held by the message server to choose an appropriate server.

Checking the Load-Balanced Group Logon


1 Make sure that you have set up a logon group for your system as described in Appendix A.

Make sure that your front-end setup allows you to access this logon group from the SAP logon window.

2 In the SAP Web AS logon window of your front-end machine, log on to the SAP Web AS system with a group by choosing a <groupname>.

If virtual addressing is used, this group must be addressed virtually. If not, change the logon group setup configured in preparation for the test.

The logon screen appears.

3 In the SAP Web AS logon screen, enter the client, user name, password, and language.

Choose Return.

If your input is correct, a copyright popup appears. When you choose Enter, the popup disappears and the SAP Web AS user main menu is displayed.

4 The status line at the bottom of the logon window shows the host name of the machine you are connected to.

If virtual addressing is used, this name must be a virtual one.

Note the logon time. You can use system or local time. Later, in step 7, you need to know how much time has elapsed since the logon.

5 At the operating system level, log on as user <sid>adm to the SAP Web AS host that you have just been connected to with the group logon.

6 Enter the command: netstat -t | grep sapdp

The <hostname>.<port> for the connection between the SAP GUI and the SAP Web AS instance (dispatcher) is displayed.


February 2006 124


7 Check the host names in the netstat list to make sure that the front end is connected using the network adapter that is configured for front-end connects.

Also make sure that no further routing entries are in effect.

8 Wait until more than 5 minutes have elapsed since the last SAP Web AS logon. The SAP Web AS updates its load balancing statistics every 5 minutes.

9 Log on to the system from the front-end machine again. Choose the <groupname> logon group.

Another logon screen appears.

10 Check the status line at the bottom of the logon screen. You should now be connected to a different host machine.

11 In the SAP Web AS logon screen, enter the client, user name, password, and language. Choose Enter.

If your input is correct, a copyright popup appears. When you choose Enter, the popup disappears and the SAP Web AS main menu is displayed.

12 Repeat steps 4 to 11 until you have connected to each of the instance hosts in your SAP Web AS system.

13 After connecting once to each host, repeat steps 4 to 11 for the last time.

Your final group logon should establish a connection to a host machine that you have already been connected to.

11.2.8 Local Gateway Addresses The gateway service on the CI keeps a list of addresses that refer to the local host machine. The number of addresses that can be included in the list is limited. The list can contain 512 entries.

The test checks the number of entries currently held by the gateway and determines whether all local addresses are included in the address list.

Checking Address Entries of the Local Gateway


1 Log on sequentially to all the SAP Web AS instance hosts running the CI or AS (not the DB) at the OS level as user <sid>adm.

2 On all the hosts you have logged on to, perform the following steps:

Change to the trace directory and check the dev_rd file:

cd /usr/sap/<SID>/ <INSTTYPE><NR>/work

more dev_rd

The trace level need not be set explicitly because the gateway trace entries are

The following entry appears in the dev_rd file:

GwInitHostAdrs: my host addresses are: 1: [IP address] [hostname] 2: [IP address] [hostname]


February 2006 125

written by default. If you want, you can set the trace level in the instance profile: rdisp/TRACE =1

3 Make sure that all host names that can be used to address the local machine are included in the local gateway list.

If entries are missing, you probably have a gateway that cannot administer enough entries. You might find, for example, that several virtual addresses do not appear.

A standard installation allows 512 entries. 4 Check the other gateways in the system. To

do so, repeat steps 1 to 4 for all the CI and AS hosts and check their trace files locally.

The gwmon tool only lists a maximum of 5 addresses, even if the local gateway process recognizes more addresses. Therefore, to find out the exact number of addresses held by the gateway, you need to look at the trace files after system startup.

For more information, see Gateway Service [Page 42].

11.2.9 Initial SAP Web AS System Consistency – Transaction SICK The transaction SICK compares the kernel, DB, and OS Release to find out whether certain tables exist and are consistent in the ABAP Dictionary.

Checking Consistency


1 Log on to the CI host of the SAP Web AS system.

The front end shows the main menu.

2 Enter /NSICK in the command field of the SAP GUI.

The transaction must return the message no errors reported

11.2.10 Message and Gateway Server – Transaction SM51 You test the functionality of the message and gateway services with transaction SM51.

Checking the Message and Gateway Service


1 Start transaction SM51.

A list of all SAP Web AS instances that are currently part of the specified SAP Web AS system is displayed (see the example output below).

The output is an indication that the message server is running.

2 Check the following:

• All necessary instances must be included in the list.

• If virtual host names are configured, the virtual names must appear as part of the application server name in the first column called Name and as the host name in the second column called Host. Stationary host names must be displayed for the external AS hosts that are not addressed virtually

If virtual addressing is used, but virtual host names do not appear in both of the columns on the screen, you are probably not using the required switchover kernel patch.


February 2006 126

• If standard addressing is used, stationary (local) host names must appear as part of the application server name in the first column and as the host name in the second column.

3 Double-click on a line. The specified application server or the CI is contacted using the gateway on either side of the connection. A list of the work processes running on the SAP Web AS instance is displayed.

If the list is displayed correctly, the local gateway is functioning correctly.

The host name shown in the status line of the SAP Web AS screen must change to the name of the contacted host. If virtual addressing is used for the host, then the corresponding virtual host name must appear. For example, virtual addressing is used if the CI is on a virtually addressed cluster.

The output must be identical to the initial instance setup.

4 Repeat step 3 for all SAP Web AS instances on the list.

11.2.11 Logical RFC Destinations – Transaction SM59 First, check the logical RFC destinations by comparing the output of transaction SM51 with the RFC definitions in transaction SM59.

Checking Logical RFC Destinations



2 Open a second session by selecting System → Create session from the menu.

The second session is opened.

3 Call transaction SM51 in session 1 and transaction SM59 in session 2.

4 In SM59, expand the Internal connections by clicking on the ‘+’.

5 Check that all SAP Web AS instances displayed in SM51 have a corresponding entry in the list of internal destinations marked as active in SM59.

If you are using virtual addressing, you must see corresponding entries of the virtually addressed instances in both the SM51 and SM59 lists. You need not insert these entries by hand but they must appear automatically after system start or restart.

6 In SM59, perform the following three steps for every SAP Web AS instance of the test system:


February 2006 127

7 Double click on an instance The destination screen for the chosen instance appears.

If you use virtual addressing, notice that the Target machine field shows the local host name of the specified cluster machine and not the virtual one, even if this has been configured. This is correct. However, the RFC destination field must contain the virtual host name of the instance.

8 Choose Test connection.

A connection test screen with statistics appears. Make sure that no error messages are displayed.

9 Choose Back twice to return to the list of instances.

11.2.12 System-Wide RFC Connections – Transaction AL08 This transaction uses remote function calls to all running SAP Web AS instances to show all users that are logged on to the entire SAP Web AS system.

Displaying System Users


1 Log on to SAP Web AS on every instance in the system running a dialog service (CI, AS).

2 Start transaction AL08 from the SAP GUI that is connected to the CI.

The users logged on to all the instances in your SAP Web AS system are displayed.

3 Check whether all SAP Web AS instances and all users appear on the list.

If virtual addressing is used, the corresponding instances should be shown with virtual names.

11.2.13 External RFC Connection to SAP Web AS Switchover System This test performs an RFC from a remote SAP system to the switchover system that is currently being tested.

Testing an External RFC


Log on to the external SAP system where the switchover test system has been set up as an external R/3 destination. This must be a system different to the one you are currently testing.

For more information on how to set up the switchover system as an external RFC destination, see Appendix A.

2 Start transaction SM59 from the SAP GUI A list of RFC destination types is displayed.

3 Expand the R/3 destinations by clicking on the +.

A list of R/3 destinations appears. These are external systems that are available for RFC connections.

4

Double-click on the SAP Web AS switchover system that is being tested.


February 2006 128

5 Choose Test connection. If the connection is established successfully, you see a short list of connection statistics.

Make sure there are no error messages.

11.2.14 External RFC to SAP Web AS Switchover System at Operating System Level To test an RFC at the operating system level, use the RFC SDK tool, startrfc. This is available if you have installed RFC SDK together with your SAP Web AS system. For more information, see the installation documentation.

The startrfc tool is located in the directory /sapmnt/SID/exe/rfcsdk/bin.

Testing External RFC to the Switchover System at the OS Level


1 Log on to the UNIX host at the operating system level as user <sid>adm.

2 Execute the following RFC call to all hosts that are running SAP Web AS instances (that is, CI and AS) in the system being tested.

3 After installation of the RFC package the startrfc tool is located in the directory:

/sapmnt/SID/exe/rfcsdk/bin

At the operating level, call the RFC on the target machine as follows: startrfc -d <SID> -u <USER> -p <PASS> -t -3 -h <host> -g <gwhost> -x sapgw -F RFC_PING

where:

<SID> is your SAP system ID <NR> is the application server number of the specified host machine <USER> is a valid user in client 000 <PASS> is the user’s password <HOST> is the application server host <GWHOST> is your gateway host

Both <HOST> and <GWHOST> must be virtual hostnames if virtual addressing is used (for host machines on the cluster). Otherwise normal addressing is used.

If successful, the command does not display anything. A return file ending with .rfc contains the values returned by the call.

If an error occurs, the file dev_rfc contains trace information.

Note that the figure 197 after CUSTOMER_T shown in this example depends on the Release of your system. It is the length of the SAP DDIC structure BRFCKNA1.

11.2.15 Enqueue and Update Services – Transaction SM12 The enqueue service locks objects at the SAP level using an enqueue table. This table is held in the main memory of the enqueue host, which is normally the CI. To check communication with the enqueue service inside the system, the following test accesses the enqueue service from a non-CI instance.


February 2006 129

Testing the Enqueue and Update Services


1 Log on to an SAP Web AS instance other than the CI.

2 Start transaction SM12 from the SAP GUI. The initial screen of transaction SM12 appears.

3 Select Extras → Diagnosis. An enqueue check is performed and the results are displayed.

Make sure you get the following message:

Lock management operation mode External lock management in the central application server: <CI_app.server name> Diagnosis Test lock operations do not contain errors. No errors found Make sure that the

<CI_app.servername>

included in the message denotes the CI instance correctly. If virtual addressing is used the application server name must be virtual.

4 Go back to the entry screen of SM12.

5 Select Extras → Diagnosis in update. An enqueue check is performed for updates.

The results are displayed in 7 steps. After the 7th step you must get the following message:

No errors detected

11.2.16 Enqueue and Update Services – Program RSENQTS1 The following tests enqueue locking using standalone ABAP programs.

Testing Enqueue Locking


1 Log on to SAP Web AS on an instance other than the CI.

2 Start transaction SE38 from the SAP GUI. The initial screen for transaction SE38 appears.

3 In the Program field, enter RSENQTS.

4 Choose Execute.

The ABAP parameter screen appears.


February 2006 130


5 Leave the parameters at their preset values and choose Execute.

A list of the lock entries that have been set is displayed.

6 Check the locks with transaction SM12. Enter /OSM12 in the command field of the SAP GUI to start the transaction.

A second session is opened with transaction SM12.

7 Choose Enter in the second session. A list of lock entries appears. Compare these entries with those displayed by the program RSENQTS. The lock entries in both lists must be the same.

11.2.17 Enqueue and Update Services – Program RSENQTSA The program RSENQTSA tests termination of asynchronous updates. The ABAP routine causes a division by 0 error after about 20 seconds, forcing the update to abort.

Testing the Abortion of Asynchronous Updates


1 Log on to SAP Web AS on the CI host and start transaction SM12 from the SAP GUI.

The entry screen for transaction SM12 appears.

2 Start a session with transaction SM50 by entering /OSM50 in the command field. Make sure that at least this session is running on the CI.

A second session with SM50 is opened.

3 Start a session with transaction SE38 by entering /OSE38 in the command field of the SAP GUI.

A third session with SE38 is opened.

4 Be prepared to perform the next 3 steps in rapid succession:

In SE38, enter RSENQTSA in the Program field and choose Execute.

Continue with step 5 immediately.

The system informs you of the steps being executed by the program.

5 Switch to the SM12 session and choose Enter.

Proceed with step 6 immediately.

Two lock entries for the ABAP program are shown.

The ABAP program in SM50 and the two lock entries should disappear after approximately 20 seconds.

6 Switch to the SM50 Session and choose Refresh.

An update work process running an ABAP program is displayed.

7 In SM50, keep choosing Refresh until the ABAP disappears from the work process list. This takes about 20 seconds.

When the ABAP disappears, a popup notifies you of an express document.

9 On the popup, select Inbox to access the SAPoffice Inbox.

The inbox contains the message :

Verbuchung wurde abgebrochen.

View and delete the message.

10 Switch to the SM12 session and choose The two lock entries previously shown in SM12


February 2006 131

Refresh. do not appear. Instead, you see the message:

No lock entries found

11 Switch to the SE38 session and choose Back.

Start transaction SM13 by entering /NSM13 in the command field of the SAP GUI.

In the initial screen of SM13, choose Enter.

The aborted update record is displayed with the status Err.

12 Click on the update record once and select Updated Records → Delete-Single from the menu. Confirm the popup that appears.

The update record disappears.

11.2.18 Update Service – Program VBTST300 The ABAP program VBTST300 tests asynchronous updates, using the database table TCPIC.

Testing Asynchronous Updates


1 Start transaction SE38 from the SAP GUI. The initial screen of transaction SE38 appears.

2 In the Program entry field, enter VBTST300 and choose Execute.

The program parameter screen is displayed.

4 Type C in the Opcode field. Choose Execute.

The test table TCPIC is cleared. The ABAP program returns the message:

Update test program TCPIC table entries deleted

5 Return to the parameter screen. In the Opcode field, enter I for insert.

Choose Execute.

The ABAP program is executed. The parameter screen remains visible.

6 Start a session with transaction SE16 by entering /OSE16 in the command field of the SAP GUI.

A second session with transaction SE16 is opened.

7 In transaction SE16, type TCPIC in the Table Name field. Choose Enter.

The selection screen for table TCPIC is displayed.

8 Choose Execute. The record you inserted with the VBTST300 program, using the I option, is displayed. Only this record should appear.

9 Using the arrow button, scroll to the right several times until you find the field Named Buffer.

The Buffer field contains the text you entered in the Text field of the VBTST300 parameter screen. If you did not enter a text, the default text TEST is displayed.

10 Choose Back and exit the transaction.

11.2.19 Time-Periodic Batch Jobs – Transaction SM37 Batch jobs that are not dedicated to a specific host are automatically distributed to all instances that provide batch services within the system. The instance that processes the batch job is chosen dynamically. A periodic job that has finished is scheduled to run again after the defined interval. It is started on an instance that has a free batch work process.

To get an overview of all scheduled batch jobs, use transaction SM37 as follows:


February 2006 132

Checking Time-Periodic Batch Jobs


1 Start transaction SM37 from the SAP GUI. The initial screen of transaction SM37 appears.

2 Leave the default entries and choose ENTER.

A list of batch jobs and their status appears.

3

Look for the two time-periodic jobs that you created in preparation for the tests:

SO TPERIODIC NOTARGET SO TPERIODIC CIHOST

For information on preparations for the test, see Appendix A [Page 104].

The present status of the following two jobs is displayed:

SO TPERIODIC NOTARGET SO TPERIODIC CIHOST

You should see several jobs with the status finished and one of each with the status released.

Be careful not to confuse the EPERIODIC and the TPERIODIC jobs.

4 For both types of jobs, select a line with the job status finished and choose Display.

The batch job details are displayed.

5 Check whether the status is finished.

Check whether the Target host is the CI for both types of time-periodic jobs. If virtual addressing is used, the Target host field must contain the virtual host name of the CI.

11.2.20 Event-Periodic Batch Jobs – Transaction SM37 This test starts two event-periodic batch jobs. One runs on a dynamically assigned instance, the other on a specified target host. In preparation for the test, you should already have created the two batch jobs and the corresponding events to initiate them. For more information on preparing the tests, see Appendix A [Page 104].

The test uses the SAP tool sapevt to raise the events that trigger the batch jobs.

Testing Event-Periodic Batch Jobs


1 Log on to one of the host machines of the cluster as user <sid>adm.

2 Log on to the SAP Web AS system and call transaction SM37.

3 In the Start after event field, enter: SO*

Choose Enter.

The list of batch jobs that are driven by the SO* events and corresponding status information is shown on the screen.

There must be at least one batch job with the following released status:

SO EPERIODIC NOTARGET

Be careful not to confuse the EPERIODIC jobs with the TPERIODIC jobs.

4 At the operating system level, raise the event

If successful, SAPEVT does not return a message. Make sure no errors are reported in


February 2006 133

SO EVENT NOTARGET. To do so, call the SAPEVT tool located in the directory:

/sapmnt/<SID>/exe

Use the commands: sapevt SO EVENT NOTARGET -t pf=/sapmnt/<SID>/profile/ DEFAULT.PFL

the file /sapmnt/<SID>/exe /dev_evt.

5 Choose Refresh in the SM37 screen.

Another batch job called


with the status finished is added to the old list.

Again, there must be another batch job with the status released called:


6 Click on the finished batch job and choose Display. Make sure the job ran successfully on the CI. If virtual addressing is used, a virtual host name must be displayed.

7 Now find the job dedicated to run on the CI in the batch job list displayed in SM37.

The list of batch jobs driven by the SO* events, with corresponding status information, must contain at least one job with the status released called.

SO EPERIODIC CIHOST

8 At the operating system level raise the event SO EVENT CIHOST by calling the SAPEVT tool located in the directory /sapmnt/<SID>/exe. Use the commands: sapevt SO EVENT CIHOST -t pf=/sapmnt/<SID>/profile/ DEFAULT.PFL

If successful, SAPEVT does not return a message. Make sure no errors are reported in the file /sapmnt/<SID>/exe /dev_evt

9 Choose Refresh in SM37.

An additional batch job called SO EPERIODIC CIHOST with the status finished must appear in the old list. Again, one of the batch jobs listed must be called SO EPERIODIC CIHOST and have the status released.

10 Click on the finished batch job and choose Display. Make sure the job has run successfully on the CI. If virtual addressing is used, the virtual host name must be displayed.

11.2.21 Spool Service – Transactions SPAD and SP01 This test prints a list with the printer you have set up in preparation for the spool service test.


February 2006 134

Testing the Spool Service


1 Start transaction SPAD from the SAP GUI. The initial screen of transaction SPAD appears.

2 Select Output devices and choose Display. A list of defined printers is displayed.

3 To print the list of printers, choose Output device → Print this list.

The Print Screen List Screen appears.

4 Enter the name of the printer you set up for the test in the Output device field.

Select Print immediately. Do not select Delete after print.

Choose Print. If an information popup appears choose Enter.

The list of printers is displayed again. At the bottom of the screen the following message appears:

Spool request(...) created

Note the number of the spool request.

5 Start transaction SP01 by entering /NSP01 in the command field of the SAP GUI.

The entry screen of transaction SP01 appears.

6 Choose Enter to get a list of the spool requests created under your user.

All the spool requests created under your user are displayed.

7 Check whether the spool request you noted in step 4 appears.

Make sure that newly generated spool requests – that is, those that were created after the switchover – have finished correctly.

If the output status is Compl., the list has been sent to the printer.

8 Only requests that were not completed at the time of failure remain in a non-completed status. For these, Compl. does not appear in the Output status column.

To check these requests, choose Output requests. On the following screen, choose Display log.

The log that is generated for errors is displayed. Make sure that only requests sent immediately before the failure or switchover are displayed.

11.2.22 SysLog – Transaction SM21 This test checks the SAP Web AS SysLog.

Checking the SysLog


1 Start transaction SM21 by entering /NSM21 in the command field of the SAP GUI.

The initial screen of transaction SM21 appears.

2 In the From field, enter the date and time when you started the tests or when you last checked the SysLog during the tests.

Select Problems only and choose Refresh SysLog.

A list of SysLog entries referring to problems of the current day is displayed.

3 Go through the list to locate critical messages.

Check the SysLog for messages that might indicate severe problems caused by the switchover.


February 2006 135

11.2.23 Dump analysis – Transaction ST22 The following checks whether any ABAP short dumps have occurred.

Checking for ABAP Short Dumps


1 Start transaction ST22 by entering /NST22 in the command field of the SAP GUI.

The initial screen of transaction ST22 appears. It shows how many short dumps have occurred on the current day

2 If short dumps have occurred, choose Display list.

The list of short dumps created is shown.

3 Check the dumps for severe problems.

To select short dumps for a longer period, choose Selection or Goto-Statistics from the menu.

11.2.24 Update Records – Transaction SM13 This test checks the update records.

Checking the Update Records


1 Start transaction SM13 by entering /NSM13 in the command field of the SAP GUI.

The initial screen of transaction SM13 appears.

2 Check the default selections. Normally you can leave the preset values and choose Enter.

If everything is in order, no update records appear. If the list is not empty, check the update records.

To check an update record, place the cursor on the relevant line and choose Updated Records → Test .

11.2.25 Transport System - Transaction SE01 This test creates a transport request to a dummy system and releases it for export.

Testing a Transport


1 Log on to the SAP Web AS as user DDIC. Do not use the user account SAP*.

Start transaction SE06 from the SAP GUI.

The initial screen of transaction SE06 appears.

2 Choose Configuration → Overview. Choose System list.

The systems recorded in table TSYST are displayed.

3 If your SAP system has no entry yet, choose Change and enter your SAP system ID with a short description. Also enter the target system ZZZ for the test transport. This is a dummy entry. Save the entries and go back.

You are back on the entry screen of transaction SE06.

4 Start transaction SE01 by entering /NSE01 in the command-field.

The initial screen of transaction SE01 appears.

5 Choose Request → Create → Transport Request.

A new transport request is created and the Change transport request screen appears. The


February 2006 136

transport request is automatically assigned a number.

6 Enter a short description, for example: Switchover test and ZZZ as the target system. This should appear when you choose F4 on the Target system field.

Select type T, Transport of copies.

Save the transport request and choose Editor.

The (empty) object list of your transport request appears.

7 Choose Insert line. A new line is inserted on the screen.

8 Enter the object to transport as follows: For PgmID enter R3TR For Obj enter PROG For Obj.name enter RSPFPAR

Save the entries and go back.

The Change transport request screen of SE01 appears.

9 Choose Release and export to release your transport request.

You receive the message

Your objects

10 To check the success of the export, view the transport log.

The different transport steps are shown. The test import is not successful because the dummy system ZZZ does not exist.

11.2.26 Internet Control Framework This test checks different URLs.

Testing URLs


1 Try URL: http://<hostname>:<port>/sap/public/ping

where <hostname> is the fully qualified virtual hostname of the server.

Server erfolgreich erreicht.

2 Try URL: http://<hostname>:<port>/sap/public/icman/ping

server <hostname> on host <hostname>_<sid>_<instance> (<client>) successfully reached

3 Try URL: http://<hostname>:<port>/sap/bc/echo

GET /sap/bc/echo HTTP/1.1

4 Try URL: http://<hostname>:<port>/sap/bc/bsp/sap/it00

A test application Standard BSP Test Application on System <sid> should occur with several test links.

Appendix C: Preparations for SAP Web AS Java Compliance Tests

February 2006 137

12 Appendix C: Preparations for SAP Web AS Java Compliance Tests The SAP Web AS Java has a default configuration after installation, so you need not perform extra configuration activities (apart from setting up RFC destinations as described below) in order to test whether the switchover software setup complies with the SAP Web AS system.

See Appendix D: SAP Web AS Java Compliance Tests [Page138] for a description of the overall test procedure and step-by-step instructions on how to perform the SAP Web AS functionality tests.

12.1 Setting Up SAP Web AS Java for RFC Communication In order to use RFC calls from/to your SAP Web AS Java system, you need to register it as an RFC server to a SAP Gateway. You do that by registering an RFC Destination and an existing repository through the JCo RFC Provider Service on the J2EE Engine.

For a detailed description of the setup procedure, refer to the JCo RFC Provider Service documentation in SAP Library [Page 9]:

SAP Library SAP NetWeaver Application Platform (SAP Web Application Server) Java Technology in SAP Web Application Server Administration Manual Server Administration J2EE Engine Administration Web Application Server Integration JCo RFC Provider Service

Appendix D: SAP Web AS Java Compliance Tests

February 2006 138

13 Appendix D: SAP Web AS Java Compliance Tests This appendix describes the test procedure that we recommend for all vendors who want to offer switchover products for an SAP Web AS Java environment. The overall test procedure includes a number of SAP Web AS functionality tests that you have to perform:

• Once before the switchover • Once after the switchover • Once after the switchback

The following sections give step-by-step instructions on how to perform the functionality tests. We only examine SAP Web AS Java system functions, not business applications or transactions, but these should function normally as in the standard system.

Before you begin the functionality tests, it is important to prepare your system as described in Appendix C: Preparations for SAP Web AS Java Compliance Tests [Page 137].

Contents13.1 Overall Test Procedure...............................................................................138

13.2 SAP Web AS Java Functionality Tests .....................................................................139 13.2.1 Check General Status of the Instance Processes ........................................................................ 139 13.2.2 Basic Network Testing.................................................................................................................. 139 13.2.3 Availability of the Enqueue Server ............................................................................................... 143 13.2.4 Testing Enqueue Server Operations ............................................................................................ 144 13.2.5 Message Server Functionality ...................................................................................................... 145 13.2.6 Telnet Connection......................................................................................................................... 146 13.2.7 HTTP Connections ........................................................................................................................ 147 13.2.8 P4 Connection............................................................................................................................... 147 13.2.9 Asynchronous Communication .................................................................................................... 148 13.2.10 Log Viewing ................................................................................................................................ 148 13.2.11 Testing DataSources................................................................................................................... 149 13.2.12 Naming Service Availability........................................................................................................ 150

13.1 Overall Test Procedure When the test environment has been set up and the tests have been prepared as described in Appendix C: Preparations for SAP Web AS Java Compliance Tests, you can begin with the actual testing procedure. For each chosen scenario, you have to complete the following procedure to test all the switchover functions provided for the SAP Web AS:

1. Start the SAP Web AS Java system under the control of the switchover product.

2. Run the SAP Web AS Java functionality tests (see below).

3. Perform the switchover as specified for the scenario.


5. Perform a switchback, that is, re-establish the setup of the initial scenario.


7. Shut down the SAP Web AS Java system under the control of the switchover product.

We recommend you to record the following information when you run the tests:

• Technical details of the test setup (hardware, network setup, and SAP Web AS setup).


February 2006 139

• Execution of the tests, noted on a test sheet.

• Reports on problems that occurred (these should be sent to SAP).

• Test logs (for example, SAP Web AS Java server trace files (defaultTrace.trc files), DB logs, OS logs).

13.2 SAP Web AS Java Functionality Tests

13.2.1 Check General Status of the Instance Processes Use the jcmon native program to check the availability of the processes running the current Web AS Java instance.

This program is part of the Java Startup and Control Framework. It is located in the following directory:

<drive>:\usr\sap\<SID>\<INSTANCE NAME>\j2ee\os_libs (on MS Windows platforms);

/usr/sap/<SID>/<INSTANCE NAME>/j2ee/os_libs (on UNIX platforms);

Checking the Status of an Instance

Step Action Result

1 Launch the program by executing the following on the command line:

jcmon pf=\usr\sap\<SID>\SYS\profile\<SID>_<InstanceID>_<host>

Where the pf option points to the location of the instance profile file. An example command line is:

jcmon pf=\usr\sap\J2E\SYS\profile\J2E_JC00_ivaylo-i

The Main Menu of the program appears on the screen.

2 Enter option 20 to access the Cluster Administration Menu.

The output lists all processes within the instance along with status information.

If you find that any of the processes within this instance is not running, you can have a look at the following log or trace files located in the \usr\sap\<SID>\<INSTANCE NAME>\work directory:

• startsap.log and startsap.trc – to ensure the database and the JControl process were successfully started.

• dev_jcontrol – to view any errors that occurred when executing the bootstrap and the JLaunch processes.

• any of the log_bootstrap_ID<elementID> files – to view errors in the bootstrap process for the corresponding Instance process (dispatcher, server, SDM).

• jvm_<component name>.out - The standard and error output file of the JVM running the corresponding JLaunch process.

13.2.2 Basic Network Testing Correct network addressing is an essential prerequisite for running the SAP Web AS system in a switchover environment. Therefore, testing the SAP Web AS network connections is of fundamental importance and one of the primary tasks of switchover software tests. The tests here assume that you have set up your network as described in Network Configuration for SAP Web AS Switchover [page 74]. The setup is a prerequisite for running the tests successfully.


February 2006 140

The network tests use SAP’s niping tool, which is a standalone program. It uses the SAP-specific network interface that lies above TCP/IP. The SAP interface is also referred to as the network interface layer (NI). You can use the tool to reliably test the network connections between the host machines in the Web AS cluster. If testing already fails at the niping level, you cannot continue because this indicates that the network setup is not functioning correctly.

The tool provides an option to function as a client/server pair running independently of the SAP Web AS. The client/server test works as follows:

• The niping server is started on the target host of the connection.

• The niping client accesses the niping server by specifying a network host name.

• The niping client can be initiated to perform a loop that gives you time to check whether the server and the client side of the connection are both actually using the correct LAN interfaces. This check is possible on either the niping server or client host. The network host names (mapped to IP addresses via the name service) are used to identify the connected interfaces.

To access help, enter niping without specifying any additional parameters.

The niping tool can be found in the \usr\sap\<SID>\<INSTANCE NAME>\exe in a Windows environment and under UNIX in the /sapmnt/<SID>/exe directory of your installation.

You must perform the test in this section on the active SCS node. Otherwise they will fail

Basic Network Functions and Configuration

This test checks the basic functionality of the network software and the proper setup locally, on all host machines that are part of the system. This includes the cluster and all attached machines.

To complete the test, execute niping –t on the command line on all nodes in the cluster.

If this basic test fails, analyze the error messages issued by niping. Your network might be configured incorrectly or the network software might be corrupt so that it cannot be used by the SAP Web AS.

LAN Connections

This test checks the network connections that use the LAN interfaces as specified in SAPLOCALHOST and SAPDBHOST profile parameters.

The following describes the checks necessary for the front-end LAN connections and front-end access to the SAP Web AS system.

The test looks at the following:

• Host connections for network traffic

• Functions of the network software

• NIC configuration

• Name service

• Appropriate settings for the SAP profile parameters SAPLOCALHOST and j2ee/dbhost

When you run the test, check all possible combinations. You must prove that every possible instance can act successfully both as a niping client and niping server. You must check all the following host combinations:

• SCS host to DB and all AS hosts

• DB host to SCS and all AS hosts


February 2006 141

• All AS hosts to SCS and DB hosts

In a test environment there might be up to two AS instances, as described in the scenario definitions. For more information, see Switchover Scenarios[Page 46]. In the following matrix, which helps you visualize all test combinations, the application servers are referred to as AS1 and AS2.

While running the tests, fill in the blank fields in the matrix when a check has been completed successfully.

Client host

SCS DB AS1 AS2

SCS

DB

AS1 serv

er h

ost

AS2

If you are running a central SCS/DB system with an external AS instance, the SCS is never separate from the DB instance. In this case, you can reduce testing to the combinations:

• SCS/DB host to all AS hosts

• All AS host to SCS/DB host

The corresponding check matrix looks like this:

Client host

SCS/DB AS1 AS2

SCS/DB

AS1

Ser

ver h

ost

AS2


February 2006 142

Use the test matrix, when you go through the following test procedure:

Testing LAN Connections

Step Action Result

1. Choose an SAP Web AS instance from the first column of the matrix. The corresponding host machine <server_name> is the niping server host.

2. On the niping server host, run niping in server mode using the command:

niping -s

The following message appears on the screen:

<date and time>

ready for connect from client

The niping server waits for incoming client requests. It shuts down if being idle for more than 300 seconds.

3. Choose a SAP Web AS instance type from the matrix headings. The corresponding host machine <client_name> is the niping client host.

4. On the niping client host, run niping in client mode by executing:

niping –c –H <server_name> -L2 –D 30000

Then, within 60 seconds, proceed with the step 5 to check the connection.

Notes:

Depending on the switchover technology you use, you have to test the following for <server_name> in the –H option:

• the stationary hostname of the specified server host in case of identity takeover switchover. This is the network name that maps to the stationary IP address.

• the virtual hostname of the specified server host in case of virtual IP address switchover.

To execute the test correctly, the value of the <server_name> argument for the –H option above must be identical to the names configured in the SAP parameter settings:

• If the niping server is running on the SCS or AS, use the name configured in their local instance profile as SAPLOCALHOST parameter.

• If SAPLOCALHOST parameter is not set, use the local hostname of this machine.

• If the niping server is running on the DB host, use the name configured as j2ee/dbhost parameter. This is usually set in the system-wide default profile.

The niping client responds with:

<date and time>

connect to server o.k.

The niping server responds with:

<date and time>

connect from host <client_name> o.k.

The niping client accesses the niping server with the network name <server_name>. The client performs two loops (the –L option) with a delay of approx. 30 seconds (-D option, time given in milliseconds).

Looping gives you 60 seconds to perform the check described in step 5. You can extend that time if necessary.


February 2006 143

Depending on the switchover technology in use, you must use different kinds of host names:

• For products with identity takeover you must use standard, stationary host names;

• For products with virtual IP address switchover you must use the virtual host names.

Cluster-external AS instances are always addressed by stationary host names.

5. On the niping server host, check the netstat list. The connection must be established using the LAN interfaces that correspond to your setup. Check the network host names on both sides.

According to the network setup specified in this documentation, this name must always be the local host name of the specified machine.

Also, check that no further routing entries are in effect to access the LAN.

6. To test all possible client hosts, repeat the procedure from step 3 onwards.

7. To test all possible server hosts, repeat the procedure from step 1 onwards.

8. Check all niping client/server combinations remaining in the matrix.

Depending on the type of switchover scenario you are using, also do the following:

• SO-1 and SO-2 scenarios

If the SCS and DB are usually located on two host machines during normal operation, they are addressed using two different network names or addresses, for example scs and db. After a switchover in scenarios SO-1 and SO-2, they are both on a single host. However the two names for accessing the services are still available. Consequently you must check both connections using the original names, even though they are running on a single machine. In the above example you need to check both scs and db.

• SO-3 scenario

If, during normal operation, the SCS and DB are always located on a single host, they are addressed using a single network name, for example, scsdb. In this case, you only need check a single connection to the central system. In the example this is the network name scsdb.

Make sure that the test setup and the results comply with the network setup specified in Network Configuration for SAP Web AS Switchover [page 74].

13.2.3 Availability of the Enqueue Server Use the Enqueue Server Monitor native program to send a dummy request to check if the Enqueue Server is running. This program is located in the following directory:

<drive>:\usr\sap\<SID>\<INSTANCE NAME>\exe (on MS Windows platforms);

/usr/sap/<SID>/<INSTANCE NAME>/exe (on UNIX platforms);


February 2006 144

Checking enqueue server availability

Step Action Result

1 Launch the program by executing the following on the command line:

ensmon pf=\usr\sap\<SID>\SYS\profile\<SID>_<Central_InstanceID>_<host>

Where the pf option points to the location of the instance profile file for the central services. An example command line is:

ensmon pf=\usr\sap\J2E\SYS\profile\J2E_SCS01_ivaylo-i

The program menu appears on the screen.

2 Execute option 1. You must get the following message if the enqueue server is running:

Dummy request executed successfully with rc=0

If you get an error while executing the dummy request, you can check the dev_ensmon trace file, as well as log and trace files of the enqueue server for error analysis. You can view those files using the option 3 of the ensmon program. For further information, refer to the help provided with the program (option h).

13.2.4 Testing Enqueue Server Operations Use the enqt native program to test different functions of the standalone enqueue server, as well as the consistency of the locking table. This program is located in the following directory:



Testing Enqueue Server Functions

Step Action Result

1 To display the lock statistics, execute the following on the command line:

enqt pf=\usr\sap\<SID>\SYS\profile\<SID>_<SCS_InstanceID>_<virt_scs_host> 31

A list with various enqueue statistics is displayed.

The occupancy of the lock table is important for monitoring the lock mechanism. This should never overflow. An overflow is pending if the Peak Util for Owner Names, Granule Arguments, or Granule Entries is equal to or has nearly reached the maximum value.

2 To check the contents of the lock table in the shared memory against the backup file, execute the following on the SCS host:

enqt pf=\usr\sap\<SID>\SYS\profile\<SID>_<SCS


February 2006 145

_InstanceID>_<virt_scs_host> 3

3 To dump the content of the lock table to a text file, execute the following on the SCS host:


The file ENQDUMP is generated in the same directory where the enqt program resides. Open it with a text editor to view the contents of the lock table.

4. To test whether the enqueue server is able to set optimistic locks and convert such to exclusive ones, use the enqt program’s function to emulate optimistic locking load. Execute the following:


You can use use additional parameters for this OpCode 15 of the program to adjust the number of optimistic lock to be set, the number of conversions to exclusive locks and the repetition count of those operations. For more information refer to the help provided with the enqt program.

If successfully executed, you get a table showing the locking operations performed by the enqueue server during the load emulation.

5. To simulate the SD benchmark test execute the following:


You can monitor the locks with an additional enqt process instance. To do this type:

enqt pf=\usr\sap\<SID>\SYS\profile\<SID>_<SCS_InstanceID>_<virt_scs_host> 6 2

On the secondary instance you will see the list of locks within the server. This list should grow and shrink during test progress. To stop the SD benchmark interrupt the process.

13.2.5 Message Server Functionality Use the msmon native program to check availability of message server, to retrieve a list of all application servers connected to the message server, and retrieve information about configured logon groups. This program is located in the following directory:



Availability Check

To check if the message server is running, you can execute the following on the command line:

msmon pf=\usr\sap\<SID>\SYS\profile\<SID>_<SCS_InstanceID>_<virt_scs_host> -mshost <virtual SCS host>

If the Message Server Monitor program attaches successfully to the message server, this is an indication that the latter is running.


February 2006 146

Make sure that the rdisp/mshost and rdisp/msserv parameters are set in the profile file you provide to the command. Otherwise, the monitor program will not be able to attach to the message server (even though the latter is running!)

List of Application Servers

The message server on the SCS instance keeps a list of application servers that can be reached within the system. The list is important for the load-balancing procedure. Use the web interface to access message server. In your browser, execute http://<mshost>:<msport>/msgserver/text/logon, where the <mshost> must be the value of the rdisp/mshost parameter in the instance profile file, and the <msport> is the HTTP access port of the message server as defined by the ms/server_port_<xx> parameter in the same profile file.

The result is a page containing a list of all Web AS Java instances that are available in the cluster. For each instance the ID of the corresponding Java dispatcher is displayed, as well as as the registered HTTP and P4 ports. Also, the information about the load balancing power of the instance is displayed, which represents the number of the server processes available to process client requests. You should check if this list is complete.

Here is an example of a logon information returned by the message server for a Web AS Java setup with single instance with one dispatcher and one server process:

version 1.0

J2EE2371800

J2EE Ivaylo-I 50000 LB=1

P4 Ivaylo-I 50004 LB=1

13.2.6 Telnet Connection To test telnet connections to J2EE Engine elements within a Web AS Java instance, you connect a telnet terminal to the Java dispatcher of this instance. This test can also help you in viewing the availability of server processes within the instance.

The telnet port on the Java dispatcher is calculated based on the instance number. The formula is 50000+100*instance_number+8.

Testing Telnet Connections

Step Action Result

1. To connect to the Java dispatcher of a selected instance using telnet you need to specify the host it is running on and the access port. For example, to establish the telnet connection on Windows platform, you execute the following in the command prompt:

telnet <host> <port>

The Logon screen of the J2EE Engine appears.

This denotes that Telnet Service on the Java dispatcher is running and telnet connections can be accepted.

2. Enter a user and a password. You are logged on to the J2EE Engine.

3. Execute the JUMP command on the command line. You get the IDs of all available server processes within the instance that are attached to the Java dispatcher.

You can compare the number


February 2006 147

of server processes attached to this dispatcher returned by the message server when executing the http://<mshost>:<msport>/msgserver/text/logon

URL and the one returned by the JUMP command.

13.2.7 HTTP Connections Test the HTTP availability by requesting following URLs:

Step Action Result

1. Try URL:

http://<hostname>:<port>/

where the port value is calculated using the following formula: 50000+100*instance_number

Note that this URL will be successfully executed only if the default web application on the J2EE Engine is started. That is, in case of switchover this depends on the startup state of the application. The state must be “ALWAYS”, which means the application is automatically started after server processes startup.

The J2EE Engine Start Page is displayed in your browser.

13.2.8 P4 Connection To test whether P4 connection can be established to the Java dispatcher within a particular Web AS Java instance, use the Visual Administrator tool to connect using the default transport layer (that is, using P4 protocol).

Connecting Visual Administrator to the J2EE Engine

Step Action Result

1 Start the Visual Administrator tool by running the go script file located in the \usr\sap\<SID>\<Instance>\j2ee\admin directory.

The connection wizard screen appears.

2. Create a new connection by selecting New.

3. Enter a display name of the connection and select Direct Connection to a Dispatcher Node.

4. Enter the username of the user to logon with this connection, the host name (that is, the virtual host name) and the port. The port is calculated using the following formula: 50000+100*instance_number+4

Leave the Transport Layer to Default.

You need to create different connections for different hosts you want to connect to. This means that you


February 2006 148

need to create as many connections as the number of the Web AS Java instances you have.

5. Choose the appropriate connection from the list in the Connect to SAP J2EE Engine screen.

The Login screen appears.

6. Enter the password for the corresponding user and choose Connect.

You get the Connected to <host name> message on the status bar at the bottom.

13.2.9 Asynchronous Communication Use the JMS shell command to check availability of Java Message Service (JMS) on Web AS Java.

Testing JMS Availability

Step Action Result

1. Repeat the steps 1 to 3 as described in the P4 Connection[Page] procedure above.

You get the IDs of all available server processes within the instance that are attached to the Java dispatcher.

2. Execute JUMP <ID> on the command line to access the server process with the specified ID.

3. Execute ADD JMS to add the JMS shell commands group to the shell environment on the server process.

4. Execute JMS LIST Displays information about configuration of available JMS instances, as well as active connections, sessions, a list of producers and consumers, browsers and durable subscriptions.

13.2.10 Log Viewing Use the Standalone Log Viewer to view system log and trace files for system error analysis. The Standalone Log Viewer does not depend on the state (started or stopped) of the J2EE Engine (compared to the LogViewer integrated into the Visual Administrator).

Using Standalone Log Viewer

Step Action Result

1 Start the Standalone LogViewer. For more information on how to do that, refer to the Standalone LogViewer’s documentation located at \usr\sap\<SID>\<instance_name>\j2ee\admin\logviewer-standalone\Logviewer_Userguide.pdf.

The Standalone LogViewer’s server part is started on the host(s) where the log files reside. The client part is connected to the server part. The LogViewer’s user interface is displayed on the screen.

2. Register the Log files that you want to view to the LogViewer. Do the following to achieve that:

1. On the left pane, select the host name where the directory containing the log files exists.


February 2006 149

2. To register multiple log files from a log directory, choose File -> Add Files from LogDirectory from the main menu.

3. To add the log files for the Java dispatcher, browse to the following directory in the Select the LogDirectory screen: <drive>:\usr\sap\<SID>\<Instance_name>\j2ee\cluster\dispatcher\log

To add the log files for the server process, repeat the step and browse to <drive>:\usr\sap\<SID>\<Instance_name>\j2ee\cluster\server<ID>\log

3. View the following log files for possible error messages:

dispatcher->.\log->defaultTrace.trc

dispatcher->.\log->system->network.log for possible network errors

dispatcher->.\log->system->server.log for possible errors with services on the dispatcher.

server<ID>->.\log->defaultTrace.trc

server<ID>->.\log->system->database.log for possible error with database access.

server<ID>->.\log->system->server.log for possible errors with services on this particular server process.

13.2.11 Testing DataSources To test if your configured DataSource is available and a connection to the database can be obtained, use the TEST_DS shell command.

Testing DataSources

Step Action Result

1. Repeat the steps 1 to 3 as described in the procedure above.



3. Execute ADD DBPOOL to add the DBPOOL shell commands group to the environment

4. Execute the TEST_DS shell command by providing the following on the command line:

TEST_DS <DataSourceName> <SQL_statement>

Where <SQL_statement> is a SELECT statement to get data from the database. For example: TEST_DS <DataSourceName> "select count(*) from J2EE_CONFIG;"

The command outputs data contained in the queried column.


February 2006 150

You can retrieve a list of configured DataSources by executing the GET_DS shell command on the command line.

13.2.12 Naming Service Availability Use the LSN shell command to check availability of the Naming services on the Web AS Java. Those services are important so that applications and other Web AS Java services can lookup/unbind/bind objects from/to the naming tree.

Testing Naming Service Availability

Step Action Result

1. Repeat the steps 1 to 3 as described in the procedure above.



3. Execute ADD NAMING to add the NAMING shell commands group to the environment.

4. Execute the LSN command by providing the following on the command line:

LSN /

The whole naming tree is printed on the screen.

5. Optionally, you can try to lookup a resource bound to the naming tree using the LOOKUP command:

LOOKUP <location>

where <location> is a location in the naming tree.

If lookup is successful you get information about the object value of the object bound to this location in the naming tree, and the class name representing this object printed on the screen.


February 2006 151

Index Address

parameters .......................................................... 66, 91 takeover.............................................................. 67, 92

Address configuration standard .............................................................. 66, 91 virtual ................................................................. 67, 92

Application server, definition...............................11 Backup, standard profiles and scripts ...................78 Batch jobs.............................................................40

in switchover environment ....................................... 41 not scheduled on dedicated host ............................... 40 scheduled on dedicated host ..................................... 41

Batch service ........................................................40 CCMS...................................................................43 Central instance, definition...................................10 Central system, definition.....................................11 Central system, installation ..................................79 CI and DB, separation ..........................................22 Control scripts, switchover.................................109 DB and CI node, separate installation ..................80 DB RECONNECT ...............................................24 Dialog service.......................................................31 Documentation

about this .................................................................... 7 Executables, local .................................................85 Failure

CI and DB hosts ................................................. 22, 48 File systems ..........................................................82 Frontend LAN

setup ................................................................. 75, 100 HTTP Load Balancing

Message Server based .............................................. 14 Message Server based, details .................................. 34 Web Dispatcher........................................................ 18 Web Dispatcher, details............................................ 34

ICM Architecture.............................................................. 14 Impact of failure....................................................... 38

Installation central system........................................................... 79 preparation ............................................................... 78 SAPINST ................................................................. 79 separate DB and CI node.......................................... 80 switchover units ....................................................... 65

License SAP Web AS...........................................87 standard .................................................................... 87 switchover system .................................................... 88

Logon ...................................................................31 groups....................................................................... 32 load balancing .......................................................... 32 single-LAN network................................................. 33 techniques................................................................. 32 two-LAN network .................................................... 33

MS Windows..........................................................9 MSCS......................................................................... 9

Name variables .....................................................11 Naming conventions.............................................10 Network setup

switchover options ............................................. 69, 94 NFS ......................................................................82

configuration ............................................................ 86

directories ................................................................ 86 switchover setup ...................................................... 86

NFS service .................................................... 22, 48 Printer services, configuration.............................. 42 Profile settings

CI switchover................................................68, 93, 94 DB switchover ....................................................68, 93

Remote logons...................................................... 78 RFC ...................................................................... 42

external destinations................................................. 43 internal destinations ................................................. 42

SAP J2EE Engine Architecture ............................................................. 16 EJB container........................................................... 55 Naming service, security service.............................. 56 SAP Java Connector ................................................ 61 Web container (servlet, JSP) .................................... 54

SAP Notes ................................................ 9, 63, 120 SAP Web AS

Web Dispatcher........................................................ 18 SAP Web AS compliance test preparations

creating event-periodic batch jobs...........................128 creating time-periodic batch jobs ............................127 hardware requirements............................................123 setting up logon groups ...........................................124 setting up operation modes .....................................125 setting up printers............................................130, 131 setting up remote RFC destinations ........................126 system setup............................................................123

SAP Web AS compliance tests consistency check ...................................................145 direct frontend logon...............................................141 dump analysis .........................................................155 enqueue and update services ...................................148 event-periodic batch jobs ........................................152 external RFC connections .......................................147 instance processes ...................................................134 load-balanced group logon......................................142 local gateway addresses ..........................................144 logical RFC destinations .........................................146 message and gateway service..................................145 network functions and configuration.......................136 reachable application servers ..................................140 server LAN connections..........................................136 spool service ...........................................................154 syslog ......................................................................154 system-wide RFC connections................................147 time-periodic batch jobs..........................................151 transport system ......................................................155 update records .........................................................155 update service .........................................................151

SAP Web AS instance, definition ........................ 11 SAP Web AS, Architecture .................................. 12

HTTP Load Distribution Using SAP Message Server............................................................................ 14

Internet Communication Manager (ICM) ................ 14 SAP J2EE Engine .................................................... 16

SAP Web AS, definition ...................................... 10 SAPCOMM services ............................................ 43 SAPROUTER services......................................... 43 Server LAN

routing...............................................................76, 101 setup..................................................................76, 101


February 2006 152

Services centralized ................................................................ 16 distributed................................................................. 16

Single-LAN network ......................................70, 95 central CI/DB system ......................................... 73, 98

Single-LAN Network separate CI and DB instance .............................. 70, 95

SO-4 and SO-5 four-node cluster ...................................................... 30 three-node cluster ..................................................... 29

Spool service ........................................................41 startsap and stopsap, naming conventions ............80 Startup profiles, names .........................................80 Switchover cluster

hardware requirements ....................................... 26, 52 Switchover control scripts .......................... 103, 113

NFS ........................................................................ 109 profiles ................................................................... 110 starting instances .................................................... 110 starting up database ................................................ 110 starting up primary node ........................................ 109

Switchover scenarios ............................................58

additional information.............................................. 27 definition.................................................................. 25 SO-1 and SO-2......................................................... 27 SO-3......................................................................... 28 SO-4 and SO-5......................................................... 28

Switchover units ............................................. 21, 47 Takeover

address ................................................................67, 92 Target groups, switchover manual ......................... 9 Terms, definition .................................................. 10 Transport control .................................................. 89

parameter settings .................................................... 89 Two-LAN network......................................... 73, 98

separate CI and DB instance ...............................74, 99 Update service ...................................................... 39

failure resilience....................................................... 40 Upgrade, switchover system................................. 89 WAN access

failure resilience....................................................... 44 Web Dispatcher

Architecture ............................................................. 18 Load Balancing ........................................................ 35

sap web application server in switchover environments

Documents