SAP Web Dispatcher 6.40 - Webinar Power Point

SAP Web Dispatcher 6.40 for SAP Web AS Java

Jochen RundholzNW RIG APA

© SAP AG 2004, SAP Web Dispatcher /Jochen Rundholz / 2

RIG Know How Conf Calls

Please:All participants will be muted

Questions in the Q&A section at the endImportant issues via WebEx chat

Mute your phone Use the Mute button where available or Key in *6* to mute and *6* to unmute in case you want to ask a question

Give feedback for further improvements

Introduction

Installation

Administration

Introduction Web Applications and Web ServersIntroduction Load Balancer


Requirements of Business Web Applications

Scalability and performanceScale out via additional applicaton server Loadbalancer necessaryDynamic content leads to low fraction of cachable content

TranscationalSession persistance necessary

SecurityProtection of application servers (DMZ, revers proxys, fire walls, ...)AuthenticationEncryption

StabilityHigh availibility is necessary


"Old" SAP Application Server Architecture

SAPGUI

RFCClient/Server

Dispatcher

Gate-way

RDBMS

WorkProcesses

DIA

G

RFC


SAP Web Application Server 6.40

RFCClient/Server

Browser SAPGUI

DIA

GICM

J2EEDispatcher

J2EEServer

Processes

Dispatcher

Gate-way

RDBMS

WorkProcesses

RFC

HTT

P


System Communication

ICM

MSMPI

JCo

HTTP

SAP GUI

ABAP

Central ServicesEnqueue-ServerEnqueue-Server

Message-ServerMessage-Server

SDM

Server Server. . .

Java-Dispatcher

JAVA

WP WP. . .

ABAP-Dispatcher

Internet

Web Browser/Web Server

Introduction Web Applications and Web ServersIntroduction Load Balancer


Load Balancing Design Criteria

Load balancing mechanism (client or server side)

End-to-end SSL or SSL termination in load balancer. In-depth vs. end-to-end security, need to inspect traffic Persistence mechanism (session ID or IP address) Client certificate authentication

Cost of device

Performance

Robustness and high availability

Ease of configuration and operation (TCO)

Integration into existing infrastructure and security policy


Facts and Features of SAP Web Dispatcher

UsabilitySingle point of access only one URL for user, only one official IP addressLoad balancing and configuration via message server

Scalability and performanceSoftware solution, not a hardware solution

TransactionalSession persistence via cookie (HTTP) or IP address (HTTPS)

SecurityProtection of application servers (DMZ, reverse proxy, fire walls, ...)AuthenticationSSL Termination, end to end SSL, re-encryptionSimple request filtering


Hardware Load Balancer vs. SAP Web Dispatcher

ProAdditional featuresRe-use existing infrastructureUnified Web infrastructure for all Web systems (SAP and non-SAP)

ContraCost Less integrated with SAP Web ASConfiguration, operation, maintenance requires special expertise


Load Balancing Mechanisms (Redirection & DNS)

RedirectionsSimpleBad user experience and maintenance

DNS based methodsPerhaps OK for intranetOK for global load balancingGenerally not OK for server load balancing


Drawbacks of Redirection

Many official external DNS names and IP addresses

Confusing for the user, bookmarking destroys load balancing

With SSLServer certificate must match URLEvery application server needs separate server certificateHigh administrative overheadExpensive

May lead to unnecessary user authentication dialogs


Load Balancing Mechanisms (Server Side)

Load balancing deviceTransparent for clientAlways the same URL One official IP address for all application serversOne server certificate for all serversTechnically challengingUsually preferable

LoadBalancer

ApplicationServer

ApplicationServer

ApplicationServer


Web Dispatcher

SAPWeb

Dispatcher

MessageServer

CentralInstance

DialogInstance

DialogInstance

RDBMS

http://web.acme.com


Web Dispatcher For Multiple SAP Web AS

Multiple Web Dispatchers on different TCP ports

Not recommendedJ2EE session cookies overwrite each other.SSL to port other than 443often not possible

https://web

SAP WebDispatcher

CorporateNetworkSAP Web

AS

SAP WebDispatcher


AS

443

444

https://web:444IP


Web Dispatcher For Multiple SAP Web AS

Multiple Web Dispatchers on different (virtual) IP addresses

Recommended

https://web1

SAP WebDispatcher


AS

SAP WebDispatcher


AS

443

443

IP1

IP2

https://web2


Integration Into Web Server / Reverse Proxy

SAP WebAS

Web Server

Reverse ProxyModule

Fir

ew

all

Static WebPages

Internet

443

Fir

ew

all

/sap*

other

Integrate SAP Web AS services into Web site

Optional Web Dispatcher for Scaling

Forward requests for/sap* to SAP Web AS


Network Security

Optional high security network with internal firewall

Internal ServerNetwork

High SecurityNetwork

Secure ServerNetwork (DMZ)

Internet

Database

DB

DB

ApplicationProxy

SAP WebApplication

Server

R/3, FI, HRetc.

Web Servers ApplicationsProtected

Applications

Fire

wal

l

Fire

wal

l

Fire

wal

lFi

rew

all

Intern.Firew.

Internal Server

Network

Secure Serv.Network(DMZ)

Internet

DB

ApplicationProxy

SAP WebApplication

Server

Web Servers Applications

Fire

wal

l

AccessRouter

&Firewall

Fire

wal

l

Firewall

Introduction

Installation

Administration

SizingInstallationHigh Availability


CPU Sizing

No measurements available yetMain factor is the usage of SSL

No SSL at allTermination of SSLTermination and re-encryption of SSL

Termination of SSL is expensiveRe-encryption is not very expensive since only the handshake is expensive and the handshake between server and SAP Web Dispatcher has to be done only every couple of hours


Memory sizing

Memory usage for internal tables Server tables

Holding information about connected serversUsually very small (90 kB default, few MB for very large system)

Connection tablesHolding information about the open connectionsconcurrent_conn = (users * req_per_dialog_step *conn_keepalive_sec)/ (thinktime_per_diastep_sec)mpi/total_size_mb = (concurrent_conn * mpi_buffer_size)/(1024* 1024)

Default: mpi_buffer_size = 32kBDefault: mpi/total_size_mb = 500

End to End SSL table1.8 MB for 10.000 entries


Installating the SAP Web Dispatcher

Media for the web dispatcher is provided with the J2EE kernel:

C:\usr\sap\<SID>\<Central-Instance>\exe\sapwebdisp.exeicmadmin.SAR

To install and setup the SAP Web Dispatcher:

1. Download kernel files from SAP service market place

2. Extract kernel using sapcar -xvf

3. Copy the sapwebdisp.exe and icmadmin.SAR files to a directory on what is to be the Web Dispatcher host.

4. Use sapcar –xvf to extract the icmadmin.SAR file into that directory.

5. Execute sapwebdisp –bootstrap to generate an initial profile for the Web Dispatcher

6. Start the web dispatcher with sapwebdisp pf=sapwebdisp.pfl


Download from service.sap.com/download


Unpack kernel

These are only the minimum files sometimes additional files might be used/helpful


Unpack icmadmin.SAR & Folder Structure


Configuring the SAP Web Dispatcher

Necessary Input

Important Information


Basic files after installation

Developer Trace

Hashed Password of User

SAP Web Dispatcher executable

SAP Web Dispatcher profile


Additional Information

Some additional information regarding the installationVersion information via sapwebdisp -vTrace file dev_webdisp in web dispatcher directoryMS platforms: msvcp71.dll and msvcr71.dll must exist (OSS 684106)Start SAP Web Dispatcher viasapwebdisp.exe pfl=<drive>:\<path>\sapwebdisp.pflOSS notes: 538405


Web Dispatcher High Availability

High availabilitycluster

SAP WebDispatcher

SAP WebDispatcher


AS

Fail-Over

RedundantNetwork

Infrastructure


High Availability of SAP Web Dispatcher - Basics

Some basic informationFail over software has to be provided by hardware partnerNo automatic restart possibility of web dispatcher process in case of process crash on MS or iSeries platformsAutomatic restart possibility given on UNIX platforms via watchdog


Watchdog on UNIX

Setup on watchdog on UNIXStart the SAP web dispatcher with the option –auto_restartThe SAP web dispatcher will fork and creates a child processBoth processes have access to the same resourcesThe child process will take over the actual work, the parent process provides the watchdog functionality

Introduction

Installation

Administration & Configuration

BasicsLoad BalancingSession PersistenceSSL Options


sapwebdisp.pfl

Typical Web Dispatcher Parameter File:


Basic Profile parameters

These are the most basic profile parametersSAPSYSTEM

Must be unique on the host and must be in the range between 0 – 98Used to distinguish shared memory segments of different SAP WebDispatchers on the same host

rdisp/mshostHostname of the host where the message server is running (in case of double stack installation the ABAP MS has to be used)

ms/http_portPort of the message server

wdisp/auto_refreshTime to refresh internal routing tables

icm/server_port_0protocol and port where the dispatcher is listening for incoming requests

icm/http_admin_0Configuration of admin access


Administration Tool

dev_wdispsapwebdisp.pfl plus default values

sapwebdisp -v


Load Balancing Mechanism: Overview

Load balancing device needs information about system state

ConfigurationManualRetrieve from SAP Message Server (hosts, port numbers, ...)

Load balancingRound-robin (weighted)Load-basedUse information from SAP Message Server

High availabilityCheck individual Web AS instancesUse information from SAP Message Server


Load Balancing Server Determination


Load Balancing: Capacity

Capacity value is provided by message server

Capacity of an instance is equal to the number of server processes of that instance

Capacity value from message server can be overwritten by configuration (OSS note 645130)


Load Balancing Strategy

wdisp/load_balancing_strategy

weighted_round_robin (default): requests are distributed in turn to the servers, depending on their relative capacity

Preferable for end to end SSL

simple_weighted_round_robin: requests are distributed in turn to the servers, depending on their absolute capacity

Preferable for very large systems (amount of application servers)


Load Balancing: Overruling Message Server

Set the parameter wdisp/server_info_location =

UNIX: file:///<Path>/info.icr

MS: file://C:\< Path>\info.icr

The file info.icr looks likeVersion 1.0J2EE3537200J2EE host1 50000 LB=2P4 host1 50004 LB=2

J2EE23799700J2EE host2 50200 LB=1P4 host2 50204 LB=1

The format is:J2EE<Server node>J2EE <hostname> <Port> LB=<capacity>P4 <hostname> <Port> LB=<capacity>

LB values have to be identical


Monitoring Load Balancing

These values change over time, according to the load balancing

strategy


Load Balancing + Stateful User Sessions

LoadBalancer

ApplicationServer

ApplicationServer

SessionState

1st request

2nd request


Stateful User Sessions

Complex applications are usually statefulHold database locks Store intermediate SQL results etc.Session state persistent between requests ("roll area")

HTTP is a stateless protocolSuccessive requests may open a new network connection

SAP Web AS uses session ID to recognize user sessionSession cookiePart of the request URL ("URL rewriting")


Persistence Mechanisms

Session ID (Cookie or URL)Detect actual application need for session persistenceRequires no state in load balancer, because SAP session ID contains application server instance nameRequires access to clear text HTTP request (Termination of SSL in LB)

IP address of clientWorks also with encrypted trafficProblems with proxies not good for InternetNo way to detect stateless requestsProblems with alternative host names

Cookies inserted into the data stream by load balancerWorks "out-of-the-box"Problems with some SAP applicationsRequires access to clear text HTTP request


Secure Socket Layer

Encryption is required for business applicationsProtect user credentials (e.g. passwords)Data security

Secure Socket Layer (SSL)

SSL encrypts entire communication between browser and server

Server authentication (mandatory)Browser verifies, that server certificate matches URL

Client authentication with X.509 certificates (optional)Server takes identity of user from browser certificate

End point of SSL session is either Application Server (end-to-end security)Web infrastructure component (in-depth security)


Web Dispatcher In DMZ

Web Dispatcher is an application layer gateway, but does not have full reverse proxy functionality.

Internet

Fire

wal

l SAP WebDispatcher

CorporateNetwork

Fire

wal

l

SAP WebAS

Possiblyfilter

requests

End-to-end SSL orSSL Termination

Encrypted orclear text traffic


Web Dispatcher End-to-end SSL Mode

ProClient authentication with X.509 certificatesEnd-to-end data securityLoad balancer is "untrusted" component

ContraPersistence based on client IP address only Load balancing problems

ProxiesEnd-of-sessionBut: IP address based persistence usually OK in intranet

No logon groupsNo distinction between J2EE and ABAP applications


End-to-End SSL Revisited

All servers used by an SAP Web Dispatcher share the same certificate

Good: few certificates

host2

LoadBalancer

ApplicationServer

ApplicationServer

host2

externalhost2

LoadBalancer

ApplicationServer

ApplicationServer

external

SAP System

host1

LoadBalancer

ApplicationServer

ApplicationServer

host1SAP System

host1

LoadBalancer

Server

host1

host1host1internal

ApplicationServer

host1host1Application

host2

host2host2

Bad, because:

Every load balancer must use an exclusive set of servers

Multiple load balancers must use non-overlapping groups of servers

Example: different URLs for internal and external users


Web Dispatcher SSL Termination Mode

ProPersistence based on application session IDLogon groups Detection of application type (ABAP / J2EE), select correct server Request parsing and URL FilteringSSL re-encryption is possible

ContraHarder to configureWeb Dispatcher becomes "trusted component“ (secure channel to WebAS needed)Make sure Web Dispatcher does not become performance bottleneck


Please provide any feedback to improve our services!

[email protected]

Feedback

Thank You !


Questions?

Q&A

SAP Web Dispatcher 6.40 - Webinar Power Point

Documents

Transcript of SAP Web Dispatcher 6.40 - Webinar Power Point