Technical Infrastructure Guide

Planning Guide
Technical Infrastructure Guide - SAP NetWeaver PI 7.1

Document Version 1.1 December, 2007
Copyright 2007 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.
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. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials
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, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
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. SAP Library document classification: PUBLIC
Disclaimer 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. Documentation in the SAP Service Marketplace You can find this documentation at the following address:
http://service.sap.com/instguidesNW
Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used by SAPs Support Services and may not be modified or altered in any way.
Terms for Included Open Source Software

This SAP software contains also the third party open source software products listed below. Please note that for these third party products the following special terms and conditions shall apply. SAP License Agreement for STLport SAP License Agreement for STLport between SAP Aktiengesellschaft Systems, Applications, Products in Data Processing Neurottstrasse 16 69190 Walldorf Germany ( hereinafter: SAP )
The conditions indicated in the above permission notice are met; The following copyright notices are retained when present, and conditions provided in accompanying permission notices are met: Copyright 1994 Hewlett-Packard Company Copyright 1996,97 Silicon Graphics Computer Systems, Inc. Copyright 1997 Moscow Center for SPARC Technology. Copyright 1999,2000 Boris Fomitchev Copyright 2001 SAP AG Permission to use, copy, modify,
and you ( hereinafter: Customer )
distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Hewlett-Packard Company makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Silicon Graphics makes no representations about the suitability of this software for any
1.
Subject Matter of the Agreement a. SAP grants Customer a non-exclusive, nontransferable, royalty-free license to use the STLport.org C++ library (STLport) and its documentation without fee. b. By downloading, using, or copying STLport or any portion thereof Customer agrees to abide by the intellectual property laws, and to all of the terms and conditions of this Agreement. c. The Customer may distribute binaries compiled with STLport (whether original or modified) without any royalties or restrictions. d. Customer shall maintain the following copyright and permission notices on STLport sources and its documentation unchanged: Copyright 2007 SAP AG e. The Customer may distribute original or modified STLport sources, provided that:
purpose. It is provided "as is" without express or implied warranty. Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Moscow Center for SPARC Technology makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. Boris Fomitchev makes no representations about the suitability of this software for any purpose. This material is provided "as is", with absolutely no warranty expressed or implied. Any use is at your own risk. Permission to use or copy this software for any purpose is hereby granted without fee, provided the above notices are retained on all copies. Permission to modify the code and to distribute modified code is granted, provided the above notices are retained, and a notice that the code was modified is included with the above copyright notice. Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission 2.
notice appear in supporting documentation. SAP makes no representations about the suitability of this software for any purpose. It is provided with a limited warranty and liability as set forth in the License Agreement distributed with this copy. SAP offers this liability and warranty obligations only towards its customers and only referring to its modifications. Support and Maintenance SAP does not provide software maintenance for the STLport. Software maintenance of the STLport therefore shall be not included. All other services shall be charged according to the rates for services quoted in the SAP List of Prices and Conditions and shall be subject to a separate contract.
3.
Exclusion of warranty As the STLport is transferred to the Customer on a loan basis and free of charge, SAP cannot guarantee that the STLport is error-free, without material defects or suitable for a specific application under third-party rights. Technical data, sales brochures, advertising text and quality descriptions produced by SAP do not indicate any assurance of particular attributes.
4.
Limited Liability a. Irrespective of the legal reasons, SAP shall only be liable for damage, including unauthorized operation, if this (i) can be compensated under the Product Liability Act or (ii) if caused due to gross negligence or intent by SAP or (iii) if based on the failure of a guaranteed attribute. b. If SAP is liable for gross negligence or intent caused by employees who are neither agents or managerial employees of SAP, the total liability for such damage and a maximum limit on the scope of any such damage shall depend on the extent to which its occurrence ought to have anticipated by SAP when concluding the contract, due to the circumstances known to it at that point in time representing a typical transfer of the software. c. In the case of Art. 4.2 above, SAP shall not be liable for indirect damage, consequential damage caused by a defect or lost profit. d. SAP and the Customer agree that the typical foreseeable extent of damage shall under no circumstances exceed EUR 5,000. e. The Customer shall take adequate measures for the protection of data and programs, in particular by making backup copies at the minimum intervals recommended by SAP. SAP shall not be liable for the loss of data and its recovery, notwithstanding the other limitations of the present Art. 4 if this loss could have been avoided by observing this obligation. f. The exclusion or the limitation of claims in accordance with the present Art. 4 includes claims against employees or agents of SAP.
Typographic Conventions
Type Style Example Text Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation Example text Emphasized words or phrases in body text, graphic titles, and table titles Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.
Icons
Icon Meaning Caution Example Note Recommendation Syntax
EXAMPLE TEXT
Additional icons are used in SAP Library documentation to help you identify different types of information at a glance. For more information, see Help on Help General Information Classes and Information Classes for Business Information Warehouse on the first page of any version of SAP Library.
Example text
Example text
<Example text>
EXAMPLE TEXT
Document History
Document History
The technical infrastructure guide is regularly updated on SAP Service Marketplace at service.sap.com/instguidesNW.
Make sure you have the latest version of the technical infrastructure guide by checking SAP Service Marketplace immediately.
The following table provides an overview of the most important changes: Version 1.0 (May, 2007) 1.1 (December, 2007) Important Changes First released version Second version
SAP NetWeaver PI 7.1, December 2007
Contents
Contents
1 Introduction
1.1Target Audience 1.2Additional Information 1.3Prerequisites
1
1 1 1
SAP System Architecture

2.1Application Server Instance Primary Application Server Instance Additional Application Server Instance 2.2Central Services Instance 2.3Database Instance 2.4 Topology Strategies for Scalability Single Machine Topology Separating the Database Instance 2.5Adaptive Computing
2
2 2 3 3 3 3 4 5 5 5
High Availability Support for Failover Clustering (HA)

3.1Protecting System-Critical Components Switchover Units Failure and Switchover of SAP NetWeaver Application Server Instances Internet Communication Manager (ICM) System Landscape Directory (SLD) Central Services Instance Failure Failure and Switchover of the Database Server 3.2High Availability Installation Scenario Rules
6
7 7 8 8 9 9 10 12
Installable Software Units
13
4.1Systems with Usage Types 13 Application Server ABAP (AS ABAP) 13 Application Server Java (AS Java) 17 Application Server Java (AS Java) and Application Server ABAP (AS ABAP) as an ABAP+Java System 20 Process Integration (PI) 22 4.2Standalone Engines 26 Search and Classification (TREX) 27 Content Server 32 Gateway 33 Web Dispatcher 33
Web Infrastructure
5.1Technical Considerations for SAP NetWeaver AS 5.2Load Balancing with SAP Web Dispatcher SAP Web Dispatcher SSL Options SAP Web Dispatcher on an Application Server Hardware Load Balancer vs. SAP Web Dispatcher 5.3SAP Web Dispatcher as a Reverse Proxy SAP Web Dispatcher in Demilitarized Zone 5.4High Availability Failure of the SAP Web Dispatcher SAP Web Dispatcher in a Switchover Cluster Multiple SAP Web Dispatchers Behind an External Web Switch
34
34 35 35 36 36 36 37 38 38 39 40
ii
Technical Infrastructure Guide
Introduction
Introduction
This Technical Infrastructure Guide describes how you can distribute the SAP NetWeaver building blocks on physical hosts to provide stability, performance, and scalability for production systems. This guide covers the following topics: Outline of all hosts that are necessary to run the SAP NetWeaver usage types for a productive system The assignment of installable software units to the hosts Web infrastructure
1.1

Target Audience
The Technical Infrastructure Guide addresses the following groups: System administrators Consultants Hardware partners Switchover software vendors who want to test their products for compliance with the SAP NetWeaver Application Server Read this documentation if you want to implement switchover software in an SAP NetWeaver AS environment and need in-depth technical knowledge. It is also useful if you want to understand switchover strategies and the technical issues involved.
1.2
Additional Information
We strongly recommend that you also read the SAP High Availability documentation available in the SAP Developer Network (SDN): www.sdn.sap.com/irj/sdn/ha. For information about specific switchover products, contact your hardware and switchover software vendor. If you have any questions regarding the integration of SAP NetWeaver AS with a specific switchover product, contact the Competence Centers of SAPs hardware partners. For more information about switchover systems, see the following SAP Notes: Relevant SAP Notes Note number 803018 1052984 Topic Central note on high availability High Availability with SAP NetWeaver Process Integration (PI)
You can access the notes on SAP Service Marketplace at service.sap.com/notes.
1.3
Prerequisites
You have to know which installable software units and standalone engines you need and how your system landscape will look like. More information: Master Guide - SAP NetWeaver, available from the SAP Service Marketplace at service.sap.com/instguidesNW.
An SAP system consists of SAP instances. An SAP instance is a group of processes that are started and stopped at the same time. In SAP NetWeaver, there are the following instances: Application server instance Central services instance Database instance All instances, except the database instance, are identified by an instance number, which is a two-digit number between 00 and 97 that is unique on a host. Instances can reside on one host, or they can be distributed on several hosts.
The terms dialog instance and central instance are no longer applicable to the architecture of SAP NetWeaver, and are therefore no longer used.
2.1

Application Server Instance

Dispatcher Work processes (dialog, background, spool, or update) Gateway Internet Communication Manager (ICM) Internet Graphics Service (IGS) optional
The application server of usage type AS ABAP includes:
The minimum installation is the central services instance and one application server instance.
Primary Application Server Instance

If you have an ABAP-only system, you can also install an all-in-one central instance with enqueue work process and message server on the same host. More information on the architecture: help.sap.com/nwpi71: English SAP Library SAP NetWeaver Process Integration Library Application Server Infrastructure View Function-Oriented
In such a case, the message server and enqueue server are part of the application server instance. This instance is therefore called the primary application server instance. In addition, if you decide to configure any services onto a single server instance, this server instance becomes a primary application server. As such, an unprotected primary application server instance is a potential single point of failure. It needs to be protected in High Availability scenarios. SAP recommends to avoid primary application server instances in cluster environments.
Additional Application Server Instance

Additional application server instances are optional and can be installed on separate hosts. For usage type AS ABAP, they include: Dispatcher Work Processes (dialog, background, spool, or update) Gateway Internet Communication Manager (ICM) Internet Graphics Service (IGS) optional
A cluster always needs a load balancing solution, such as SAP Web dispatcher.
2.2
Central Services Instance
The ABAP central services instance (ASCS) forms the basis of communication and synchronization for the ABAP clusters. The ASCS can only be installed for a high availability system with AS ABAP. A central services instance consists of the message server and the enqueue server: Message server Only one message server can run on each AS ABAP usage type. The message server handles the communication between the additional application server instances and also supplies information to the SAP Web dispatcher about load balancing. Enqueue server The enqueue server contains a lock table that handles logical database locks.
2.3
Database Instance
The database instance is a mandatory installation component for the installation of an SAP system. AS Java and AS ABAP have separate database schemes. When AS ABAP with AS Java (also known as Java Add-In) is installed, the AS ABAP and the AS Java database schemes are installed in the same database. It is not recommended to use separate databases for the AS Java and AS ABAP scheme. The ABAP scheme is named SAP<SAPSID>.
2.4
Topology
This section introduces some basic topologies for an SAP system. A topology is a schematic description of the layout of a system or network. In terms of an SAP system, the topology describes the arrangement of an application server as a cluster with one or more physical machines. The topology of an SAP system also addresses scalability, performance, availability, maintainability, and security.
Strategies for Scalability

The scenario that is installed on an SAP system can require the application server to scale up or scale down an application. Therefore, scalability is very important for efficiency, performance, and cost reduction. One strategy is to distribute the components to different physical machines, avoiding multiple uses of resources such as memory and CPU. Another strategy for distributing the load is using vertical and horizontal scaling in a cluster environment: Vertical scaling is a technique for a cluster arrangement that includes many additional application server instances created on one physical machine. The single machine needs enough resources to handle this configuration. We recommend that you monitor performance and memory before adding a new application server instance. You can set up vertical scaling whenever required as it does not need any special installation steps.
Application Server Machine 1
HTTP Requests
Central Services Instance

Central Services
Dialog Dialog AS Instance Instance Instance
Database
Horizontal scaling is another clustering technique that distributes the additional application server instances across multiple physical machines. This configuration provides failover support and so ensures high availability of the application server processes. The disadvantages of this strategy are the increased installation and maintenance effort and also the cost of additional machines.
Application Server Machine 1 Machine 3 Machine 2 Machine 4
HTTP Requests
Central Service Instance

Central Services
AS Instance
Database
Single Machine Topology

This type of topology presents a configuration where all components reside on the same machine. It is easy to install and maintain and is therefore appropriate for first-time installations when you want to test and familiarize yourself with the functions of the application server. At this stage, it is easy to determine what kind of topology is needed and to plan the system landscape. Although this topology is easy and inexpensive to configure, it has some drawbacks that you must consider. Since all components are located on a single machine, they compete for resources, and this affects the performance processes. In addition, the components cannot be additionally secured with firewalls, and high availability is not supported. This configuration can be enhanced with horizontal scaling.
Separating the Database Instance

Separating the database instance to a separate host avoids multiple uses of the same resources, as we discussed above in the drawbacks of a single machine topology. Apart from the improved performance, locating the database instance on another physical machine lets you implement high availability solutions. The database is a critical component and it is therefore very important to ensure high availability for it. Nevertheless, hosting the database instance on a separate machine adds to the complexity because you need to configure, maintain, and back up another entity.
2.5
Adaptive Computing
SAP NetWeaver enables adaptive computing, through which hardware, software, and system resources can be dynamically assigned to optimize system operation and to run at peak cost efficiency. The Adaptive Computing Controller provides a a central point from which to monitor system operation and control dynamic resource distribution in your entire landscape. Application services can be started, stopped, and relocated, and hardware resources can be assigned to application services. Mass execution tasks can be scheduled. For more information about Adaptive Computing, see service.sap.com/adaptive.
Switchover clusters guarantee high availability of the SAP system by switching critical software units across multiple hosts in the cluster. When a primary node fails, proprietary switchover software automatically switches the failed software unit to another hardware node in the cluster. Applications accessing the failed software unit experience a short delay but resume normal processing after the switchover.
The term cluster is used in information technology in the following different ways: switchover cluster, software cluster, and database cluster. The first one, switchover cluster, is described here; the second means the functionality of redundant application servers, all running the same software. This has the benefit of high availability but at the same time is also a feature for scalability. The third term means high availability for databases, which may come in different flavors. Switchover clusters also have the advantage that you can release a particular node for system maintenance by deliberately initiating a switchover. Switchover solutions can protect against hardware failure and operating system failure, but not operator errors or errors in application software. SAP NetWeaver supports Server Central Services (SCS) an instance that consists of the essential enqueue and message system services only. This has been standard for AS Java installations and now is possible for AS ABAP also. The benefit of having a separate SCS instance is mainly in the area of high availability. This approach concentrates the possible single points of failure of a system into a single instance and, therefore, ensures isolation just on them. Before the SCS entities were located on a separate functional instance, it was necessary to extend protection to a complete system. To reflect this development the, term dialog instance is no longer used in this HA documentation. From now on, instances running functional services are named "application server" (AS) instance. This means that high available SAP NetWeaver systems have only two kinds of instances, either an SCS or an AS instance. However, as there currently are still two central services instances in a SAP NetWeaver Add-In installation one for ABAP and one for Java they are called SCS and ASCS. The critical components in a SAP system are: Central services instance (SCS and ASCS) with message server and enqueue server Database instance SAP central file system Other instances can be protected by running them redundantly. For example, you can add additional application servers.
A switchover cluster consists of: A hardware cluster of two or more different hosts to hold multiple copies of the critical software units. Switchover software to detect failure in a node and switch the affected software unit to the standby node, where it can continue operating. A mechanism to enable application software to seamlessly continue working with the switched software unit by using virtual network identity of protected instances.
Design the switchover cluster together with your hardware partner. The switchover product has to match your operating system.
We strongly recommend that all the hosts used for switchover have the same operating system.
Assuming that central services instance is running under the operating system Microsoft Windows and the DB on a UNIX platform, the central services instance can only switch to another Windows host and the DB to another UNIX host.
For more information about High Availability with SAP NetWeaver Process Integration (PI), see SAP Note 1052984.
3.1
Protecting System-Critical Components
This section describes switchover strategies for protecting critical components.
Switchover Units
Switchover components are combined in a hardware cluster for the switchover process. In the switchover process, every entity in that component is switched. To keep the downtime of an entity during switchover as short as possible, switchover groups must be as small as possible. The SAP recommendation is to group the critical components of your SAP system into the following switchover components: Central services instance Database instance Distributing the database instance from the ASCS onto two different hosts is recommended when SAP NetWeaver is running in a multi-host environment with a heavy database workload.
The saposcol process must run on the DB host to enable CCMS functions. For more information, see SAP Note 20624. File system Several directories in a SAP system are shared among all instances. Protecting files systems is handled by the cluster software solution provider.
Failure and Switchover of SAP NetWeaver Application Server Instances

The purpose of distributing the SAP NetWeaver Application Server over several instances is to avoid switchover procedures. If there is more than one distributed instance of the application server, then high availability is achieved. If one application server instance fails, the user can always reconnect to another application server instance. However, the current session is lost in this case. If session failover is also needed, this is possible for usage type AS Java. For more information, see help.sap.com/nwpi71 SAP NetWeaver Process Integration Library Function-Oriented View SAP High Availability SAP NetWeaver AS Java: High System Failure (AS Java) Availability Failover on application server instances is not recommended for performance reasons. These instances are much bigger then the SCS instances and need more resources for the switchover process. Nevertheless, it is a possible setup.
Please note that the installation procedure for Windows does not support switchover of SAP NetWeaver application server instances.
Internet Communication Manager (ICM)

The ICM lets the SAP system communicate with the outside world using the HTTP, HTTPS and SMTP protocols. In its role as a server, the ICM can process requests from the Internet that arrive as URLs with the server/port combination that the ICM can listen to. The ICM then calls the relevant local handler for the URL in question. The Internet Communication Manager (ICM) is implemented as an independent process started and monitored by the ABAP dispatcher.
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 requested again, the application gets the page directly from the ICM, when the expiration date has not expired, sends it to the client and the work process does not have to be opened. The result is much better performance.
Failure of 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. Therefore, the ABAP 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 NetWeaver AS instance, it is not a critical component 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.
For more information on the ICM, see help.sap.com/nwpi71: English SAP Library SAP NetWeaver Process Integration Library Function-Oriented View Application Server Infrastructure Internet Communication Manager (ICM)
System Landscape Directory (SLD)

The System Landscape Directory (SLD) for SAP NetWeaver is the central directory of system landscape information relevant for the management of your software lifecycle. It contains a description of your system landscape (that is, the software units that are currently installed) and a repository of software units that can be installed in your landscape. The SLD can be installed as one single local SLD, as one central SLD with sub-SLDs or multiple standalone SLDs. For more information, see the Planning Guide System Landscape Directory, which is available from the SAP Service Marketplace: service.sap.com/instguidesNW.
Central Services Instance Failure

The most critical part of a central services instance failure is the loss of the enqueue server. The locks held by the SAP system are lost and the enqueue server has to be restarted (unless you are using a replicated enqueue server). The message server is also disabled. Communication between the different application servers in the distributed system also fails or is impeded. SAP NetWeaver ensures database consistency by disabling enqueue transactions when the enqueue server is not available. After the central services instance has been switched over to another host, it has to be restarted. However, external SAP NetWeaver application servers on different hosts might still be holding open, uncommitted transactions. These can hold enqueue locks that have been lost but are not visible anywhere in the entire SAP system. If no precautions are taken, any user in the SAP system can then lock the same object and change it in the database, which can cause an inconsistent database. Therefore, all open transactions in the entire SAP system must be aborted and rolled back before the enqueue server is restarted.
System Impact The switchover of the central services instance has the following impact on your system: Transaction locks that have not yet been committed are lost at a system-wide level. All user input for all transactions that have not been finished with the ABAP command COMMIT WORK needs to be re-entered. RFC connections are maintained.
In the case of a planned central services switchover, you need to notify the users and give them a deadline to commit all their transactions.
To eliminate the enqueue server as a critical component you have to set up the enqueue server as standalone replicated enqueue server.
Enqueue Replication Server

The enqueue replication server runs on another host and contains a replica of the lock table. All clients and the replication server are connected to the SCS instance. If the SCS instance fails, it is restarted by the cluster software on the replication server, and the lock table stored on the replication server is transferred to the SCS instance. The cluster software also ensures that access attempts from clients go through the replication enqueue server while the SCS instance is out of action. If the replication server fails, it can also be restarted. It retrieves the lock table from the SCS instance when it restarts. In normal circumstances, the replication server only gets delta information for the lock table.
Failure and Switchover of the Database Server

You can use DB reconnect in all situations where the database connection fails, such as host failure, planned shutdown, or temporary interruption of the connection to the database host. This feature enables automatic reconnection to the database if the last connection was closed unexpectedly. There are two types of DB reconnect: Reconnect to the same database instance The reconnect to the same database instance is only successful if the error condition has been resolved. Reconnect to a standby database instance This setup uses parallel database technology, where application hosts are connected to one database instance with an additional database instance on another host available as a standby instance. The reconnect to a standby database instance is normally successful immediately after the DB failure, if an error does not occur on this instance as well.
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 in usage type AS ABAP: if the initial connect fails, the work process is stopped and is not restarted.
10
DB Reconnect AS ABAP
In the event of a database host failure, the network connection of SAP work processes to the DBMS is lost. 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. The DB reconnect feature makes sure that all work processes of all SAP instances are automatically reconnected to the DB as soon as the DB service is restarted and becomes available again. The work processes can transparently recover after temporary DB failure. 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. The functionality depends on the type of access service involved that is, dialog, batch, or update. For more information about the database reconnect feature for ABAP, see help.sap.com/nwpi71 English SAP Library SAP NetWeaver Process Function-Oriented View SAP High Availability SAP NetWeaver AS Intergation Library ABAP: High Availability DB Reconnect (AS-ABAP) Technical Details The DB reconnect features prevent all work processes from being shut down. For this reason, the SAP instances do not have to be restarted. If pre-defined errors are returned from the database call to a work process, this process is set to reconnect status. The transaction run by the process is terminated while the process keeps running and informs all other work processes (regardless of the type) on the host about the database restart. If the database 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.
DB Reconnect AS Java
The DB reconnect has to be handled by the application. Depending on the programming model used for database access in your applications, SAP Web AS Java provides the following reconnect mechanisms: Connections using OpenSQL and NativeSQL with Java Database Connectivity (JDBC) Connections using VendorSQL with direct JDBC connection
For more details on the database reconnect feature for Java, see help.sap.com/nwpi71 Function-Oriented View SAP High SAP NetWeaver Process Integration Library SAP NetWeaver AS Java: High Availability System Failure (AS Java) Availability Persistence Layer and Databases.
11
3.2
High Availability Installation Scenario Rules
The following set of rules is intended for setting up custom installation scenarios. These rules are intended for different operating systems and some of them may be obsolete for a particular operating system. 1. Database instance and central services instance run in different switchover groups. Databases have significant impact on switchover due to processing of transaction logs, thus it is not recommended to include them together with other components in a switchover unit. The central services do not use or need a lot of resources; therefore they can be switched very fast. Thus, it is better 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 the 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 this is not necessary. In case of a switchover, all user sessions will be lost. 4. Several switchover groups may run on the same hardware cluster. It is possible to run several switchover groups on one hardware cluster if the HA software allows this. It is also an option, to distribute them to several hardware clusters. 5. The use of an enqueue replication server is strongly recommended. The enqueue service handles locks 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 an ABAP primary application server exists, it has to be in a switchover group. This is only relevant for installations that will support high availability later, and have been installed in standard mode. In this way, the critical components 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 high availability issues and is only relevant for performance.
12
The following section provides detailed information about the most-used installation cases and specifics for ensuring high availability on them.
4.1
Systems with Usage Types
Usage types determine the role that a system plays in a particular scenario. They represent the capabilities offered by a collection of installed and configured software components. Usage types are a new structuring element of an SAP NetWeaver system on a technical level.
For more information about usage types, see the Master Guide - SAP NetWeaver on SAP Service Marketplace at service.sap.com/instguidesNW
Application Server ABAP (AS ABAP)

AS ABAP is an ABAP system and requires no other usage type. It does not include a Java EE engine. Mandatory instances of an AS ABAP system are: Primary application server instance Central services instance Database instance
Optional instances are: One or more additional application server instances
Distributing the Instances

Distributed System
13
Central System In a central system, the database instance is placed on the same host as the ABAP application server instance.
High Availability
Critical Components AS ABAP Component or Work Process Number of Configurable Units SystemWide Critical Componen ts X X X
DBMS Enqueue server Message server Dialog work process Update work process Background work process Spool work process Gateway saprouter (WAN access) NFS ICM Web Dispatcher
1 for each AS ABAP 1 for each AS ABAP (part of ASCS instance) 1 for each SAP system (part of ASCS instance) 1n for each instance 1(2)m for each instance 0q for each instance 1p for each instance 1 for each instance 0r for each AS ABAP 1 for each AS ABAP 1 for each instance Note: Web Dispatcher is a standalone engine. The SAP Web dispatcher is recommended when you use an SAP system with several SAP NW application servers for Web applications.
14
Switchover Scenario The following sections deal exclusively with host failure and switchover of the DB and SAP central services instances. 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. The switchover of AS ABAP additional application servers is not included in the SAP NetWeaver switchover scenarios for the following reasons: We strongly recommend that you configure business-critical services on multiple application servers to increase failure resilience. This ensures that a single SAP instance does not contain services that are critical system-wide components. Therefore, additional application server instances do not necessarily need to be part of the switchover cluster. If you need to centralize a particular work process that is, batch, update, spool, or gateway on one dedicated host, which in effect introduces another system-wide critical component, configure it as part of the ABAP primary application server on the switchover cluster. This means that the switchover for ABAP central services instance then also applies to this work process.
The installations described in this section concern releases of SAP NetWeaver 7.1. For older installations, see the corresponding documentation.
15
Database Instance and ABAP Central Services Instance, each in its own Switchover Group, ABAP Application Server Instance Outside
ABAP Dialog Instance
ICM
ABAP Dialog Instance

ICM
ABAP ABAP Dispatcher Dispatcher Work Work Work Work Work Work Process Process Process Process Process Process
ABAP ABAP Dispatcher Dispatcher Work Work Work Work Work Work Process Process Process Process Process Process Gateway Gateway
ABAP central services instance in its own switch-over group
Gateway Gateway
ABAP
ABAP
IGS
IGS
ABAP Additional ABAP Additional Application Server Application Server Instance Instance
ABAP Central Services Instance ENQ Server MSG Server
ABAP Central Services Instance ENQ Server MSG Server
ABAP Central Services Instance
Database Processes
Database Processes
Database ABAP Schema
This is only one of several possible configurations. If your business scenario requires a different setup of your system, then see High Availability Installation Scenario Rules on page12.
Scalability
As a general rule, when all work processes are active most of the time you can add additional work processes while the host still has enough memory and CPU resources available. The number of work processes has to be in accordance with the requirements for the dispatcher to work efficiently. An additional additional application server instance is necessary when all work processes are active most of the time and the host cannot bear additional work processes.
16
Application Server Java (AS Java)

AS Java consists of the J2EE Engine and auxiliary services. There is no ABAP application server. Mandatory instances of a Java system are: Central instance Central services instance Database instance Optional instances are: One or more dialog instances

Distributed System
Central System In a central system, the database instance is placed on the same host as the Java central instance and the Java central services instance.
17
High Availability
Critical Components AS Java Component or Service DBMS Enqueue service Message service SDM Java dispatcher Java server process NFS service Number of Configurable Units 1 for each AS Java 1 for each AS Java (part of Java-SCS instance) 1 for each AS Java (part of Java-SCS instance) 1 for each AS Java (part of CI) 1 for each Java instance 1..m for each Java instance 1 for each SAP NetWeaver X System-Wide Critical Components X X X X (*)
(*) The Software Deployment Manager (SDM) is the component for delivering applications to AS Java. The SDM is located on the central instance. If it is not available, no new software components can be deployed to AS Java. However, this might not be an issue in production environments since software updates already imply planned downtime. Therefore we do not describe high availability measures for the SDM in this document. Switchover Scenarios The following sections deal exclusively with host failure and switchover of the DB and Java central services instances of the AS Java. 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. The switchover of application server services is not included in AS Java switchover scenarios because services that are of critical importance to your business on several NetWeaver hosts are redundantly configured by default. This makes sure that a single SAP instance does not contain services that are critical system-wide components. Therefore, SAP instances do not necessarily need to be part of the switchover cluster. A Java dialog instance is connected with the database using the enqueue server. When running a server instance only on the idle host and using the switchover software to shut down the running server instance before switching, you can take advantage of the resources from both hosts.
18
Database Instance and Java Central Services instance and Java central services instance Each in its Own Switchover Group, Java Central Instance Inside
This is only one of several possible configurations. If your business scenario requires your system to be set up differently, see High Availability Installation Scenario Rules.
For systems with a high load, the database instance and the Java central services instances should be distributed to different hosts. If you want to reduce the number of idle hosts, you could run this environment on three hosts, by running only one computer in idle state. When a switchover occurs, the database or the Java central services instance switches to the computer that is currently idle.
Scalability
The default number of application threads for AS Java is 40. As a general rule, when all threads are active most of the time you can add additional server processes while the host still has enough memory and CPU resources available. Adding a dialog instance is necessary when all server processes are active most of the time and the host cannot bear additional server processes.
19
Application Server Java (AS Java) and Application Server ABAP (AS ABAP) as an ABAP+Java System
This system variant consists of AS ABAP and AS Java (ABAP+Java system). This means, that the ABAP central instance is enhanced by a Java stack on the same host. You can install an ABAP+Java system in one installation run (new system), or you can enhance an already existing AS ABAP system with a Java Add-In. Mandatory instances of an ABAP+Java system are: Central instance Java central services instance Database instance
Optional instances are: One or more dialog instances
The AS ABAP part communicates with AS Java using standard RFC calls.

Distributed System
Add-In Central Instance

ICM ABAP Dispatcher Work Process Gateway Java Dispatcher Server Process SDM
Java Central Services Instance ENQ Server (Java) MSG Server (Java) ABAP Central Services Instance ENQ Server (ABAP) MSG Server (ABAP) Critical components: Database ABAP Central Services Instance including Enqueue Server for ABAP Message Server for ABAP Java Central Services Instance including Enqueue Server for Java Message Server for Java Central file share /sapmnt/
Add-In Dialog Instance

ICM ABAP Dispatcher Work Process Gateway ABAP IGS Java Java Dispatcher Server Process
ABAP IGS
Java
Database ABAP Schema Java Schema
20
Central System In a central system, the database instance is placed on the same host as the Add-In central instance of the ABAP+Java system. High Availability The critical components of this scenario include the critical components for AS Java and AS ABAP.
Database Instance and ABAP/Java Central Services Instance, Each in Its Own Switchover Group, Add-In Central Instance Outside In this scenario, the database instance and central services instances are each in their own switchover group. This variation keeps the Add-In central instance outside of the hardware cluster, thus only running necessary parts for switchover in such an environment.
A dialog instance for an ABAP+Java system
This is only one of several possible configurations. If your business scenario requires your system to be set up differently, see High Availability Installation Scenario Rules.
Scalability
The recommendation for an Add-in is to have an AS ABAP and an AS Java Add-in on it. However, it is possible to add an Add-In DI that only contains AS ABAP in case the NetWeaver system needs more AS ABAP resources. A load balancer is needed whenever HTPP/HTTPS requests have to be processed.
21
Process Integration (PI)

The default installation variant for a Process Integration system is the all-in-one installation where all the central components, namely the central Integration Server, Integration Builder, and System Landscape Directory (SLD) are installed on one host.
PI All-in-One
AS-Java
Runtime Workbench
AS-ABAP Integration Builder

Repository Integration Engine Directory
Integration Server
Business Process Engine
Mapping Runtime System Landscape Directory Adapter Engine
All ABAP parts of the Process Integration system run on the central instance of AS ABAP. The AS Java components are also installed together in one AS Java instance. AS ABAP and AS Java can be secured as one unit. For scalability reasons, additional dialog instances for AS ABAP and AS Java can be added on different hosts. Start with the all-in-one scenario and securing all components of the all-in-one installation together by using switchover software. Thus, there are no additional actions required to consider the communication between those components when a switchover is initiated.
Using the all-in-one scenario as your starting point reduces the post-installation tasks for enabling switchover to a reasonable number and it keeps the administration of the server cluster as simple as possible.
22
High Availability
The figure below shows the major PI building blocks. The critical components are marked in gray.
Web Dispatcher (Optional)

ABAP-SCS Instance Java-SCS Instance
MSG
ENQ
MSG
ENQ
AS-ABAP Instance
AS-Java Instance
Mapping Runtime Integration Server Adapter Engine

SLD NFS DBMS Integration Repository Integration Directory NFS
Critical Components PI Component or Service AS Java/AS ABAP Enqueue Service Message Service NFS DBMS SLD Integration Repository 1m Running on AS Java 1 for each AS Java/AS ABAP (*) Integration Directory Running on AS Java 1 for each AS Java/AS ABAP (*) Integration Server Central Adapter Engine Integration Engine Business Process Engine 1 for each AS Java/AS ABAP (*) Running on AS Java Running on AS ABAP Running on AS ABAP Number of Configurable Units 1 n (*) X X X X System-Wide SPOF
23
(*) High availability is inherited from usage type AS Java and AS ABAP. For more information about critical components, see usage type AS Java and AS ABAP. Adapters Adapters may play crucial roles for PI. Adapters are required in communication involving systems where PI middleware is not built in. It is important to note, however, that the scope of adapters as critical components is restricted to specific scenarios only. In general, one failing adapter will not affect the entire PI based landscape like an Integration Server failure. For example, consider PI-based communication between two legacy SAP systems, which are accessed by using the RFC adapter at runtime. In this case, the RFC adapter is a critical component for any mission-critical RFC communication scenario between those two systems. However, IDoc-based communication with the same application systems (using the IDoc adapter) is not affected by the runtime availability of the RFC adapter. A failing RFC adapter of course will not affect independent scenarios running across the Integration Server.
Integration Repository & Integration Directory System Landscape Directory
Integration Server
Business Process Engine
http
Integration Engine
http http
http
J2SE Adapter Engine (optional)

Adapter Adapter File/ JDBC/ JMS/ Soap
Central Adapter Engine

Adapter Framework Messaging Queuing Msg. Security RFC RFC
Non-Central Adapter Engine (optional)
Other Non-Central Adapter Engines (optional)

File/JDBC/ JMS/RFC, ...
IDoc Adapter
Adapter File/JDBC/ JMS, ...
File/JDBC/ JMS/RFC, ...
File DB JMS
SAP System
Application Techn. System File/DB/JMS
Application Techn. System File/DB/JMS/RFC
Application Techn. System File/DB/JMS/RFC
24
Critical Components PI Adapter Central Adapter Engine Adapter Engine (non-central) J2SE Adapter Engine (**) Integration Server based Adapters (Idoc, plain HTTP) Number of Configurable Units 1 for each Integration Server 1 m (*) 1n Running on AS ABAP 1 for each Integration Server (*) Running on AS ABAP 1 for each Integration Server (*) (*) High availability is inherited from usage type AS Java and AS ABAP. For more information about critical components, see usage type AS Java and AS ABAP. (**) J2SE Adapter Engine is available for backward compatibility only and should not be considered in a new SAP NetWeaver system and is not described in this document. Application Systems When analyzing the high availability of the entire application landscape, it is helpful to see application systems as independent systems. The result is: An application system as such is a critical component Critical components inside an application system must be secured (for example, with switchover software) Resilience to failures in application systems must be discussed X System-Wide SPOF
PI to PI (no Adapters)
Even if PI is set up in a failure-resilient way with optimized availability, this has no impact whatsoever on how resilient to failures a sender or receiver system will be. A mission-critical application scenario needs high availability along the complete communication path. Application systems can be optimized in their availability by proper configuration and by implementing switchover software (similar to the Integration Server). For non-SAP systems, see the documentation of the specific product. For the case of other SAP usage types see the according sections in this document.
25
Scalability
Process Integration scales with AS Java and AS ABAP. Normal Process Integration message traffic enters the Integration Server using the HTTP protocol. However, if the IDoc adapter is used, message data enters the Integration Server by using the standard RFC protocol. Load balancing is also available for the RFC protocol. The AS Java and AS ABAP message server is used as the call dispatcher. RFC load balancing offers two major benefits for the PI system: Improved scalability Calls are parallelized and forwarded to several different AS Java and AS ABAP instances. Improved availability Any AS Java and AS ABAP of the Integration Server can be the target of the incoming call. Therefore, it is not necessary that a specific AS Java and AS ABAP instance is working.
With RFC load balancing activated, the sudden failure of one AS Java and AS ABAP will not affect the accessibility of the PI system by IDocs. RFC load balancing can also be used with the RFC adapter of an Adapter Engine. The adapter then registers several threads at the SAP Gateway of an RFC client system. The client system can then make use of load balancing by means of multiple SAP Gateway registration.
4.2
Standalone Engines
With SAP NetWeaver, standalone engines can be installed as additional software units. They do not offer the complete functionality of a SAP NetWeaver system, but provide specific server functionality in combination with one or more SAP NetWeaver systems.
A complete list of the standalone engines is available in the Master Guide on SAP Service Marketplace at service.sap.com/instguidesNW.
High Availability
Standalone engines have to be analyzed closely for potential single points of failure. Because standalone engines do not run on top of any Java or ABAP servers, they cannot benefit from their redundancy. In consequence this may result in the need of a switchover group for such standalone engine.
26
Search and Classification (TREX)

Overview
Search and Classification (TREX) offers an integrated set of services. TREX services include search and retrieval in large document collections, text mining, automatic document classification, and search and aggregation of structured data in SAP applications. TREX can handle text from documents in numerous formats, including Microsoft Office formats and Adobe format (PDF), and more than 30 languages. TREX search options, such as exact, Boolean, fuzzy, or linguistic searches, and classification options, such as query-based or example-based classification, provide power and flexibility for end users. TREX is based on a client/server architecture. The client component is integrated in the application that uses the TREX functions and allows communication with the TREX servers. The server component processes the requests; indexes and classifies documents, and answers search queries. TREX has the following components: Java client and ABAP client Web server with TREX extension RFC server Queue server Preprocessor Index server Name server
The figure below shows the individual components and how they communicate.
Applications using TREX SES
HTTP/HTTP S (Search Engine Serv ice)
ABAP Client
RFC/SNC
Java Client
SAP Gateway
HTTP/HTTP S
TCP/IP
RFC Server
Web Server
TRE X extension TCP/IP Possible communication paths TRE X components TRE X data storages Other components
Queue Server
TCP/IP
Index Server
TRE X engines
Name Server
TCP/IP
Queues Queues
Indices Indices
Preprocessor
27
Java Client and ABAP Client

TREX provides programming interfaces (application programming interfaces (APIs) for the Java and ABAP languages. These interfaces are also called the Java client and the ABAP client. The interfaces allow access to all TREX functions. You can use the interfaces to create indexes and queues, to perform indexing and searches. In addition, the interfaces provide functions for querying the internal status of TREX. The interfaces are part of the NetWeaver Application Server (NW AS).
Web Server with TREX Extension

The Web server is responsible for the communication between Java applications and the TREX servers. The application sends requests to the Web server in XML format using HTTP or HTTPS. The Web server converts the requests to a TREX-internal format and then forwards them to the responsible TREX servers. A TREX component that enhances the Web server with TREX-specific functions is installed on the Web server.
RFC Server
The RFC server is responsible for the communication between an SAP system and the TREX servers. The SAP system sends requests to an RFC server using an SAP Gateway. The RFC server converts the requests to a TREX-internal format and then forwards them to the responsible TREX servers.
Queue server
The queue server coordinates the processing steps that take place during indexing. It collects incoming documents, triggers preprocessing by the preprocessor and further processing by the index server. The queue server allows documents to be indexed asynchronously. This has the advantage that you can control the time of indexing. For example, you can schedule indexing for times when the system load is lower because there are fewer search queries.
Preprocessor
The preprocessor prepares documents and search queries. Document preprocessing comprises the following steps: Loading documents If the application transmits the documents as Uniform Resource Identifiers (URI) rather than directly, TREX resolves the URIs. This involves fetching the documents from the repository that the URIs reference. Filtering documents Documents can exist in various formats, such as Microsoft Word, Microsoft PowerPoint, PDF, and others. The preprocessor extracts textual content from the documents and then converts it into the UTF-8 Unicode format for further processing. Analyzing documents linguistically Linguistic analysis involves splitting text into individual words and reducing words to base forms (stems). The preprocessor uses a lexicon that exists in several languages for this. During search queries, the preprocessor performs a linguistic analysis. It transmits the results of the analysis to the index server, which continues the processing of the document.
28
Index Server
The index server is responsible for indexing, classifying, and searching. It receives requests and forwards them to the TREX engines. The engines provide the actual core functions of TREX such as: The search engine is responsible for standard search functions such as exact, errortolerant, linguistic, Boolean, and phrase searches. The text-mining engine is responsible for classification, searching for similar documents, the extraction of key words. The attribute engine is responsible for searching in document properties, such as author, creation date, change date.
Name Server
The name server manages information in the entire TREX system. It makes sure that the TREX servers can communicate with each other and that they receive all necessary information. The name server has the following tasks: Managing topology data The topology data includes information on the central components of a TREX system (TREX servers, indexes, and queues). Coordinating replication services The replication services are only relevant for a distributed TREX system. The name server has information about which TREX server has a particular data status. It makes sure that changed data is replicated. Load balancing The name server accepts requests and distributes them to the responsible TREX servers. It is responsible for distributing indexes and search queries Ensuring high availability The name server launches several watch dogs. They constantly monitor whether the TREX servers are available. If a TREX is not available, the name server ensures that the TREX server that is down does not receive any requests.
Search Engine Service (SES)

The Search Engine Service (SES) is not a TREX component, but allows users to search for business objects using TREX. SES is installed as part of the SAP NetWeaver Application Server (NW AS) together with the AS (Application Server) usage type. SES accesses TREX functions through the TREX ABAP client. SES replicates the business objects from the ABAP application to TREX, so that it can apply TREX search functions to them. When a user enters a search query, the TREX system responds to it, not the database for the ABAP application.
BI Accelerator (BIA)
The BI accelerator (BIA) allows you to improve the performance of BI queries. The BI accelerator is based on TREX technology. To use the BI accelerator you need a TREX installation based on 64-bit architecture. Hardware partners deliver this variant in a preconfigured form on a blade system as the BI accelerator box. For more information, see Installation Guide SAP NetWeaver 7.1 on SAP Service Marketplace at service.sap.com/instguidesNW.
29

Search and Classification (TREX) offers a flexible and scalable architecture. Your options range from a minimal system with one host, to a large distributed server landscape. Single-Host System A minimal TREX system consists of a single host that provides all TREX functions (indexing, classification, and searching). You can use a minimal system as a demo and test system, or as a production system. For a production system, SAP recommends that you install TREX on a dedicated host that is used exclusively for TREX.
SAP application host
TREX host
HTTP or RFC
Multiple-Host System You have numerous options for scaling TREX. You use a scaled scenario to distribute the search and indexing load between several hosts and to ensure the availability of TREX. In a multiple-host system, the individual hosts are responsible for different tasks depending on which TREX components run on them. For example, you can set up dedicated search servers with copies of the original indexes and configure automatic index replication to keep the copies up-to-date.
Master RFC M NS M QS M IS WS RFC PP File Server T RFC M NS B QS B IS WS PP Master RFC M NS M QS M IS WS PP Q Q Q Q Q Q MI MI Slaves S NS S IS Slaves
WS PP
Backup
Q Q SI SI SN SN SI Q
RFC S NS S IS
WS PP
30
Explanation of the abbreviations: Master server M NS = Master name server; M QS = Master queue server; M IS = Master index server Slave server S NS = Slave name server; S IS = Slave index server Backup server B NS = Backup name server; B QS = Backup queue server; B IS = Backup index server Other servers RFC = RFC server; WS = Web server; PP = Preprocessor Data Q = Queue; MI = Master index; SI = Slave index; SN = Index snapshot; T = Topology file TREX also supports blade systems that run on UNIX. A blade system consists of hosts in the form of server blades. A blade system has the advantage that the initial costs and running costs for maintaining the system are less than if you were using individual hosts. For more information about distribution options and implementation, see the following documentation: Installation Guide SAP NetWeaver 7.1 (Search and Classification (TREX) Single Host) Installation Guide SAP NetWeaver 7.1 (Search and Classification (TREX) Multiple Hosts)
The documents can be found at service.sap.com/instguidesNW.
31
Content Server
Content Server is a separate server instance that is used to store documents or other types of content related to SAP applications. With the accompanying cache, server content can be cached, if your company operates at several locations. This reduces the load on the wide area network when you work with documents.

The content server can run on a host with an AS ABAP instance or on a separate host. The content server can run without a DB instance or can have its own DB instance. It cannot use the DB instance of the AS ABAP.
High Availability
Content Server has the following high availability options: Failover Cluster A failover cluster consists of a primary and a backup instance on different hosts, both of which access shared data and logs. In the event of failure, a switchover is made from the primary instance to the backup instance. Processing can then continue as normal. Advantages: o o Rapid and automatic switchover Supported by SAP for Windows with Microsoft Cluster Service or platform partners for UNIX
Standby Database A standby database is a copy of the primary database. Log shipping keeps the standby database up-to-date. The log backups are regularly imported from the primary instance. If you experience problems with the primary database, you can start operating the standby database immediately, and continue working without significant downtime. Advantages: o o No storage system is needed. Therefore standby databases can run in a less expensive hardware environment. Depending on the configuration, you can restore the standby instance to the status it had at a previous point in time.
Hot Standby A hot standby system consists of a master component and one or more standby components. The hot standby system behaves like a normal database instance. The standby components must run on separate hosts. Hot standby often uses switchover software to transfer control to the standby instance. Advantages: o o Rapid and automatic switchover Processing can resume without loss of data
You must always mirror the logs of the database for all instances. For more information, see the installation documentation at service.sap.com/instguidesnw.
32
Scalability
Content server runs on a single host.
Gateway
AS ABAP can be installed as a standalone gateway. The standalone gateway has no work process types (dialog, background, update, enqueue, or spool); only the gateway process (gwrd) is started. The standalone gateway is also needed on the SLD host to enable the SLD to receive RFC calls from ABAP data suppliers. For more information, see usage type AS ABAP.
Web Dispatcher
The SAP Web dispatcher is recommended when you use an SAP system with several SAP NetWeaver Application Servers for Web applications. It is located between the Internet and your SAP system. It is the entry point for HTTP(S) requests into your system, which consists of one or more Web application servers. As a "software Web switch", the SAP Web dispatcher can reject or accept connections. When it accepts a connection, it balances the load to ensure an even distribution across the servers.
33
Web Infrastructure
Web Infrastructure
In order to run an application with stability, high performance, security, and low cost, the technical infrastructure must provide optimal support for the application. The infrastructure includes many different components, from computer hardware, operating systems, storage devices, high availability solutions to networks, load balancing devices, and firewalls. The Web infrastructure is a crucial part of the technical infrastructure. It consists of every piece of equipment needed to convey HTTP(S) requests between the browser and server. The Web infrastructure plays a meaningful role in the stability, performance, and cost of ownership of a business solution. This section outlines the technical considerations and load balancing solution approaches for building a business-ready Web infrastructure for SAP NetWeaver. More information about security: help.sap.com/nwpi71 English SAP Library Administrators Guide Security Guide SAP NetWeaver Process Integration Library
5.1
Technical Considerations for SAP NetWeaver AS
These are the most important technical requirements that must be considered when building a Web infrastructure: Load balancing mechanisms With load balancing, client requests are distributed across multiple servers in one SAP NetWeaver system. Load balancing solutions have to be used to scale a SAP NetWeaver AS system and to improve its overall performance. SAP offers the SAP Web dispatcher as a software load balancing device. Other third party software or hardware load balancer can be used as well. The load balancing product has to be compatible with your Web infrastructure components and technical requirements. Security Certain security considerations must be taken into account when designing a Web infrastructure. The most important considerations are the use of http versus https (SSL encryption), the use of reverse proxies and firewalls. Other considerations may cover the use of IDS (Intrusion detection systems).
34
Web Infrastructure
5.2
Load Balancing with SAP Web Dispatcher
Message Server AS Instance SAP Web Dispatcher http://web.acme.com AS Instance RDBMS
AS Instance
The SAP Web dispatcher is located between the Web client (browser) and your SAP system that is running the Web application. It forwards the incoming requests to the AS ABAP of the SAP system. The Web dispatcher is a load balancing solution that retrieves system administration and configuration from the message server.
SAP Web Dispatcher SSL Options

The SAP Web dispatcher supports SSL in three ways: End-to-End SSL The SAP Web dispatcher forwards the HTTPS request without decrypting it to an (HTTPS-enabled) AS Java and AS ABAP. This approach provides end-to-end data security and must be chosen if the application server where the SAP Web dispatcher is running is potentially insecure. The SAP Web dispatcher cannot read any request data, and therefore cannot interpret any session cookies that may be available (and necessary for stateful applications). The information needed for forwarding the request to the correct server is therefore missing and the SAP Web dispatcher forwards the request based on the browsers IP address. This technical restriction does not provide optimal load distribution. This option affects CPU performance. SSL termination The SAP Web dispatcher decrypts the HTTPS request, reads session cookies and performs the load balancing. Communication between the SAP Web dispatcher and the NetWeaver AS takes place through HTTP (unencrypted). SSL termination increases the need for CPU power. SSL re-encryption The SAP Web dispatcher decrypts the HTTPS request, reads necessary session cookie information and encrypts the outgoing requests. The communication between the SAP Web dispatcher and the SAP NetWeaver AS is takes place through HTTPS (encrypted). Since the SSL sessions between the SAP Web dispatcher and the SAP NetWeaver AS can be reused, this option does not need more CPU power than the SSL termination option.
35
Web Infrastructure
SAP Web Dispatcher on an Application Server

In this scenario, the SAP Web dispatcher is located on the application server of SAP NetWeaver AS. This scenario is not recommended for production installations because it can cause overload of the hardware and could therefore trpresent (especially in Internet scenarios) a security risk. A better solution is to have the SAP Web dispatcher on a separate host.
Hardware Load Balancer vs. SAP Web Dispatcher

Another solution for HTTP/HTTPS load balancing in a system landscape is using a third party hardware load balancer. In order to increase availability the hardware load balancer should be redundant in its components. The load balancers require more complicated configuration and administration for AS ABAP. Hardware load balancers can have an advantage when it comes to SSL termination / reencryption since they use a specialized hardware for the SSL operations.
5.3
SAP Web Dispatcher as a Reverse Proxy
As well as a load balancer, the SAP Web dispatcher can also act as a reverse proxy. In complex scenarios, the functions can be shared among different SAP Web dispatchers. A reverse proxy acts as an application gateway. The browser communicates only with the SAP Web dispatcher and there is no direct connection from the browser to the SAP NetWeaver AS. The SAP Web dispatcher is the gateway between two different networks (NAT network address translation). In addition to separating and connecting different networks, the SAP Web dispatcher can perform content filtering and allow access to certain resources only.
36
Web Infrastructure
SAP Web Dispatcher in Demilitarized Zone

There is always a danger of malicious access, particularly in an Internet scenario. Therefore, a certain area of the network is defined as a demilitarized zone (DMZ). The DMZ is protected by firewalls to prevent unauthorized access. If the SAP Web dispatcher is used as a reverse proxy, it is highly recommended to install it inside a DMZ. A DMZ can be quite simple as shown in the figure below but depending on the security requirements, a multi-layer DMZ can be used.
Internet
Firewall
SAP Web Dispatcher
Firewall
Corporate Network SAP Web AS-Java AS-ABAP AS
37
Web Infrastructure
5.4
High Availability
The SAP Web dispatcher is a SPOF and has to be protected by a switchover system. One scenario is to use third party switchover software and install the SAP Web dispatcher within this switchover environment. The switchover software is responsible to assign the virtual resources to the active server.
Failure of the SAP Web Dispatcher

When the SAP Web dispatcher fails, clients no longer have access to functions of the SAP NetWeaver Application Server using HTTP or HTTPS connections. Therefore, the SAP Web dispatcher has to be restarted. High availability at process level can be provided for UNIX systems using a watchdog functionality. This functionality is not available for Windows systems and is not intended to substitute a complete hardware cluster solution. The following command starts a second Web Dispatcher process. Use this command when you start the 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). Stopping the watchdog also stops the SAP Web dispatcher work process.
If only the SAP Web dispatcher work process is stopped, the watchdog starts this process again.
38
Web Infrastructure
SAP Web Dispatcher in a Switchover Cluster

You can achieve automatic failover by including 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 files (these can be also maintained locally on each cluster node) The application 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).
Internet DMZ
Switchover Cluster
Intranet
SAP Web Application Server

Firewall Firewall
Central Instance
Standby
RDBMS
DB Server Web Dispatcher Application Servers
39
Web Infrastructure
Multiple SAP Web Dispatchers Behind an External Web Switch

Another way to provide high availability of the SAP Web dispatcher is to use multiple SAP Web dispatchers behind an external Web switch. This is a realistic scenario (despite the additional effort with external Web switches) if you are already using other Web switches, but you want to use the simple configuration of the SAP Web dispatcher. Using multiple Web dispatchers eliminates the need for HA software, but at the same time imposes major limitations. This scenario does not work if End-to-End SSL is used because mapping of IP addresses is held in the main memory, and the hardware load balancer needs to forward the request to the correct SAP Web dispatcher. Furthermore, the network load balancer must support IP forwarding; otherwise, the SAP Web dispatcher will always see the same IP address and dispatch all requests to the same application server.
Internet DMZ Intranet
SAP Web Application Server

Firewall Firewall
Central Instance
Web Dispatcher Web switch (3rd party) Web Dispatcher
RDBMS
DB Server Application Servers
40

Technical Infrastructure Guide - SAP NetWeaverTM PI 7.1

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Technical Infrastructure Guide - SAP NetWeaverTM PI 7.1

Diunggah oleh

Hak Cipta:

Format Tersedia

Planning Guide