technical infrastructure guide - sap netweavertm pi 7.1
TRANSCRIPT
TeGuNe
Docum
Planning Guide
chnical Infrastructure ide - SAP tWeaver™ PI 7.1
ent 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. 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. 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. Data contained 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. SAP Library document classification: PUBLIC Disclaimer 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 SAP’s Support Services and may not be modified or altered in any way. Documentation in the SAP Service Marketplace You can find this documentation at the following address: http://service.sap.com/instguidesNW
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 )
and
you
( hereinafter: Customer )
1. Subject Matter of the Agreement a. SAP grants Customer a non-exclusive, non-
transferable, 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:
• 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, 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
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
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.
2. 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 Icons
Type Style Description
Example Text 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
EXAMPLE TEXT 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.
Example text 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.
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. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.
EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.
Icon Meaning
Caution
Example
Note
Recommendation
Syntax
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.
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 Important Changes
1.0 (May, 2007) First released version
1.1 (December, 2007) Second version
SAP NetWeaver PI 7.1, December 2007 i
Contents
Contents 1 Introduction 1
1.1Target Audience 1 1.2Additional Information 1 1.3Prerequisites 1
2 SAP System Architecture 2 2.1Application Server Instance 2
Primary Application Server Instance 2 Additional Application Server Instance 3
2.2Central Services Instance 3 2.3Database Instance 3 2.4 Topology 3
Strategies for Scalability 4 Single Machine Topology 5 Separating the Database Instance 5
2.5Adaptive Computing 5 3 High Availability Support for Failover Clustering (HA) 6
3.1Protecting System-Critical Components 7 Switchover Units 7 Failure and Switchover of SAP NetWeaver Application Server Instances 8 Internet Communication Manager (ICM) 8 System Landscape Directory (SLD) 9 Central Services Instance Failure 9 Failure and Switchover of the Database Server 10
3.2High Availability Installation Scenario Rules 12 4 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
5 Web Infrastructure 34 5.1Technical Considerations for SAP NetWeaver AS 34 5.2Load Balancing with SAP Web Dispatcher 35
SAP Web Dispatcher SSL Options 35 SAP Web Dispatcher on an Application Server 36 Hardware Load Balancer vs. SAP Web Dispatcher 36
5.3SAP Web Dispatcher as a Reverse Proxy 36 SAP Web Dispatcher in Demilitarized Zone 37
5.4High Availability 38 Failure of the SAP Web Dispatcher 38 SAP Web Dispatcher in a Switchover Cluster 39 Multiple SAP Web Dispatchers Behind an External Web Switch 40
ii SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Introduction
1 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 SAP’s hardware partners.
For more information about switchover systems, see the following SAP Notes:
Relevant SAP Notes
Note number Topic
803018 Central note on high availability
1052984 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.
SAP NetWeaver PI 7.1, December 2007 1
SAP System Architecture Technical Infrastructure Guide
2 SAP System Architecture 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 The application server of usage type AS ABAP includes:
• Dispatcher
• Work processes (dialog, background, spool, or update)
• Gateway
• Internet Communication Manager (ICM)
• Internet Graphics Service (IGS) – optional
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 Function-Oriented View Application Server Infrastructure
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.
2 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide SAP System Architecture
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.
SAP NetWeaver PI 7.1, December 2007 3
SAP System Architecture Technical Infrastructure Guide
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.
DatabaseCentral Services Instance
DialogInstanceHTTP
Requests
Application Server
DialogInstanceAS
Instance
Machine 1
Central Services
• 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.
DatabaseCentral Service InstanceHTTP
Requests
Application Server
ASInstance
Machine 1
Central Services
Machine 2
Machine 3
Machine 4
4 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide SAP System Architecture
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.
SAP NetWeaver PI 7.1, December 2007 5
High Availability Support for Failover Clustering (HA) Technical Infrastructure Guide
3 High Availability Support for Failover Clustering (HA)
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.
6 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide High Availability Support for Failover Clustering (HA)
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.
SAP NetWeaver PI 7.1, December 2007 7
High Availability Support for Failover Clustering (HA) Technical Infrastructure Guide
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 Availability System Failure (AS Java)
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.
8 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide High Availability Support for Failover Clustering (HA)
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.
SAP NetWeaver PI 7.1, December 2007 9
High Availability Support for Failover Clustering (HA) Technical Infrastructure Guide
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide High Availability Support for Failover Clustering (HA)
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 Intergation Library Function-Oriented View SAP High Availability SAP NetWeaver AS 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 SAP NetWeaver Process Integration Library Function-Oriented View SAP High Availability SAP NetWeaver AS Java: High Availability System Failure (AS Java) Persistence Layer and Databases.
SAP NetWeaver PI 7.1, December 2007 11
High Availability Support for Failover Clustering (HA) Technical Infrastructure Guide
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
4 Installable Software Units 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
SAP NetWeaver PI 7.1, December 2007 13
Installable Software Units Technical Infrastructure Guide
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
System-Wide Critical Components
DBMS 1 for each AS ABAP X
Enqueue server 1 for each AS ABAP (part of ASCS instance)
X
Message server 1 for each SAP system (part of ASCS instance)
X
Dialog work process 1…n for each instance
Update work process 1(2)…m for each instance
Background work process 0…q for each instance
Spool work process 1…p for each instance
Gateway 1 for each instance
saprouter (WAN access) 0…r for each AS ABAP
NFS 1 for each AS ABAP X
ICM 1 for each instance
Web Dispatcher 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.
X
14 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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.
SAP NetWeaver PI 7.1, December 2007 15
Installable Software Units Technical Infrastructure Guide
Database Instance and ABAP Central Services Instance, each in its own Switchover Group, ABAP Application Server Instance Outside
Database
ABAP Schema
Database Processes
Database Processes
ABAP Central Services Instance
ABAP central services instance in its own switch-over
group
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ABAP Dialog Instance
ABAP
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ICM
IGS
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ABAP Dialog Instance
ABAP
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ICM
IGS
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ABAP Dialog Instance
ABAP
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ICM
IGS
ABAP Additional Application Server
Instance
ABAP Central Services Instance
ENQ Server MSG Server
ABAP Central Services Instance
ENQ Server MSG Server
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ABAP Dialog Instance
ABAP
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ICM
IGS
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ABAP Dialog Instance
ABAP
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ICM
IGS
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ABAP Dialog Instance
ABAP
ABAPDispatcher
WorkProcessWork
ProcessWorkProcess
Gateway
ICM
IGS
ABAP Additional Application Server
Instance
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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
Distributing the 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.
SAP NetWeaver PI 7.1, December 2007 17
Installable Software Units Technical Infrastructure Guide
High Availability
Critical Components
AS Java Component or Service
Number of Configurable Units
System-Wide Critical Components
DBMS 1 for each AS Java X
Enqueue service 1 for each AS Java (part of Java-SCS instance)
X
Message service 1 for each AS Java (part of Java-SCS instance)
X
SDM 1 for each AS Java (part of CI)
X (*)
Java dispatcher 1 for each Java instance
Java server process 1..m for each Java instance
NFS service 1 for each SAP NetWeaver 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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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.
SAP NetWeaver PI 7.1, December 2007 19
Installable Software Units Technical Infrastructure Guide
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.
Distributing the Instances Distributed System
Java Schema
ABAP Schema
Database
Add-In Dialog Instance
Server Process
Java Dispatcher
JavaABAP
ICM
IGS
Gateway
ABAPDispatcher
WorkProcess
Add-In Central Instance
Server Process
Java Dispatcher
SDM
JavaABAP
ABAPDispatcher
WorkProcess
Gateway
ICM
IGS
Java Central ServicesInstance
ENQ Server(Java)
MSG Server(Java)
ABAP Central ServicesInstance
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/…
20 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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 Switch-over 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.
SAP NetWeaver PI 7.1, December 2007 21
Installable Software Units Technical Infrastructure Guide
Process Integration (PI) Distributing the Instances 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-ABAP
Integration Builder Integration Server
System Landscape Directory
Business Process Engine
Integration Engine
Adapter Engine
Repository
Directory
Mapping Runtime
AS-Java RuntimeWorkbench
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
High Availability The figure below shows the major PI building blocks. The critical components are marked in gray.
NFS
SLD
DBMS
MSG
AS-Java InstanceAS-ABAP Instance
Integration ServerMapping Runtime
ENQ
Adapter Engine
NFS
MSG ENQ
Web Dispatcher (Optional)
Java-SCSInstance
ABAP-SCS Instance
IntegrationRepository
IntegrationDirectory
Critical Components
PI Component or Service Number of Configurable Units
System-Wide SPOF
AS Java/AS ABAP
Enqueue Service Message Service NFS DBMS
1 … n (*)
X X X X
SLD 1 … m
Integration Repository 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
SAP NetWeaver PI 7.1, December 2007 23
Installable Software Units Technical Infrastructure Guide
(*) 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.
J2SEAdapterEngine
(optional)
Integration Server
SAPSystem
IDoc
Adapter
Business Process Engine
Integration Engine
Central Adapter Engine
AdapterFrameworkMessagingQueuing
Msg. Security
Non-Central Adapter Engine
(optional)
ApplicationTechn. System
File/DB/JMS
FileDB
JMS
Adapter
Adapter
ApplicationTechn. System
File/DB/JMS/RFC
Integration Repository & Integration Directory System Landscape Directory
RFC
Adapter
Other Non-Central
Adapter Engines(optional)
ApplicationTechn. System
File/DB/JMS/RFC
http
http
httphttp
File/JDBC/JMS/Soap
File/JDBC/JMS, ...
File/JDBC/JMS/RFC, ...
File/JDBC/JMS/RFC, ...
RFC
24 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
Critical Components
PI Adapter Number of Configurable Units
System-Wide SPOF
Central Adapter Engine 1 for each Integration Server
Adapter Engine (non-central) 1 … m (*)
J2SE Adapter Engine (**) 1 … n X
Integration Server based Adapters (Idoc, plain HTTP)
Running on AS ABAP
1 for each Integration Server (*)
PI to PI (no Adapters) 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
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.
SAP NetWeaver PI 7.1, December 2007 25
Installable Software Units Technical Infrastructure Guide
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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.
QueuesQueues
TREX components
Othercomponents
TREX data storages
HTTP/HTTPS
RFC/SNCHTT
P/H
TTP
S
TCP
/IP
TCP/IPTCP/IP
TCP/IP
IndicesIndices
SES(Search Engine Serv ice)
Applications using TREX
ABAP Client
SAP Gateway
RFC Server
Index ServerTREX engines
Queue Server Name Server
Preprocessor
Java Client
Web ServerTREX extension
Possiblecommunicationpaths
SAP NetWeaver PI 7.1, December 2007 27
Installable Software Units Technical Infrastructure Guide
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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, error-tolerant, 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.
SAP NetWeaver PI 7.1, December 2007 29
Installable Software Units Technical Infrastructure Guide
Distributing the Instances 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.
RFC WS
S NSS IS
PP
Slaves
RFC WS
M NSM QSM IS
PP
Master
File Server
T
QQ QQQMI QMI
QSISISIQSN QSN
Backup
RFC WS
M NSB QSB IS
PP
Slaves
RFC WS
S NSS IS
PP
RFC WS
M NSM QSM IS
PP
Master
30 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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.
SAP NetWeaver PI 7.1, December 2007 31
Installable Software Units Technical Infrastructure Guide
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.
Distributing the Instances 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 Rapid and automatic switchover
o 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 No storage system is needed. Therefore standby databases can run in a less expensive hardware environment.
o 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 Rapid and automatic switchover
o 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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Installable Software Units
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.
SAP NetWeaver PI 7.1, December 2007 33
Web Infrastructure Technical Infrastructure Guide
5 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 SAP NetWeaver Process Integration Library Administrator’s Guide Security Guide
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide Web Infrastructure
5.2 Load Balancing with SAP Web Dispatcher
SAPWeb
Dispatcher
MessageServer
ASInstance
ASInstance
ASInstance
RDBMS
http://web.acme.com
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 browser’s 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.
SAP NetWeaver PI 7.1, December 2007 35
Web Infrastructure Technical Infrastructure Guide
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 / re-encryption 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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide 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
Fire
wal
l SAP WebDispatcher
CorporateNetwork
Fire
wal
l
SAP WebAS
AS-JavaAS-ABAP
SAP NetWeaver PI 7.1, December 2007 37
Web Infrastructure Technical Infrastructure Guide
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 SAP NetWeaver PI 7.1, December 2007
Technical Infrastructure Guide 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 Intranet
RDBMS
SAP Web Application Server
CentralInstance
ApplicationServers
DB Server
Fire
wal
l
Fire
wal
l
WebDispatcher
Standby
Switchover Cluster
SAP NetWeaver PI 7.1, December 2007 39
Web Infrastructure Technical Infrastructure Guide
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
RDBMS
SAP Web Application Server
CentralInstance
ApplicationServers
DB Server
Fire
wal
l
Fire
wal
l
WebDispatcher
WebDispatcher
Web switch(3rd party)
40 SAP NetWeaver PI 7.1, December 2007