Serverauswahl und Lastausgleich durch den SAP Web Dispatcher (SAP-Bibliothek - Architektur des SAP Web Application Servers)

Serverauswahl und Lastausgleich durch den SAP Web Dispatcher

Die Zuordnung eines HTTP-Requests zu einem Server erfolgt in zwei Stufen. HTTPS-Requests werden am Schluss des Abschnitts behandelt.

Zunächst ermittelt der SAP Web Dispatcher, ob der eintreffende HTTP-Request an einen ABAP- oder J2EE-Server weitergeleitet werden soll. Er ermittelt eine Gruppe von Servern im SAP-System, die den Request ausführen können.
Innerhalb dieser Gruppe wird dann ein Lastausgleich durchgeführt.

Ermitteln der Servergruppe

Falls kein J2EE-Server aktiv ist, wird im stateless Fall der Request dem SAP Web AS gegeben, der gemäß Lastausgleich an der Reihe ist. Die Servergruppe, die den Request bearbeiten kann, ist die interne Gruppe !ALL aller SAP Web AS des Systems. Falls es sich um eine stateful Verbindung handelt, wird der SAP Web AS gewählt, der die Transaktion bearbeitet.

Falls ein J2EE-Server aktiv ist, wird die Liste der ICF-Präfixe durchsucht. Beginnt die URL mit einem Präfix, das im HTTP-Service-Baum gefunden wird, so wird der Request der Servergruppe !DIAG gegeben. Ansonsten wird er der Gruppe !J2EE gegeben. Die Gruppen werden im Abschnitt SAP Web Dispatcher unter Funktionsumfang beschrieben.

Für die Startseite, bzw. das Root-Verzeichnis, gibt es eine Sonderbehandlung, weil man bei der Suche durch die Liste der Präfixe nicht nach dem Root-Verzeichnis suchen kann (es würde immer gefunden werden, weil alle URLs mit / beginnen). Falls es sich bei der URL um eine Root-URL handelt, dann bestimmt der Profilparameter is/HTTP/default_root_hdl, welches Root-Verzeichnis benutzt werden soll. Zulässige Werte sind abap und j2ee, der Wert kann auch dynamisch, mit der Transaktion RZ11 oder SMMS, geändert werden.

Folgendes Flussdiagramm zeigt den verwendeten Algorithmus.

Diese Grafik wird im zugehörigen Text erklärt

Die Entscheidung, ob es sich um ein SAP-Präfix handelt, wird im Folgenden im Detail beschrieben. Bei der URL http://hostname:port/A/B/C ist das zu untersuchende Präfix also die Zeichenfolge /A/B/C.

Der SAP Web Dispatcher muss also entscheiden, ob es sich um ein SAP-Präfix handelt, was an den ABAP-Server (dem ICF) gegeben werden soll, oder um ein dem ICF unbekanntes Präfix (was dann an den J2EE Application Server geht) handelt. Hierzu verwendet er folgendes Verfahren.

Diese Grafik wird im zugehörigen Text erklärt

Beispiel

Wird die URL http://saphost:8080/index.html eingegeben, ist das zu untersuchende Präfix /index.html. Dies wird in der URL-Mapping-Tabelle nicht gefunden, und es enthält nur einen Schrägstrich. Ist nun der Parameter is/HTTP/default_root_hdl auf j2ee gesetzt (Defaulteinstellung), so wird im Root-Verzeichnis des SAP J2EE Application Servers nach der Datei index.html gesucht. Diese wird dann über den ICM des Applikationsservers dem Client zurückgegeben.

Arbeiten mit Logongruppen im SAP-System

Falls der Request an einen SAP Web AS gegeben werden soll, dann muss noch geprüft werden, ob für diese URL eine Logon-Gruppe (Pflege in der Transaktuion SMLG) definiert ist. Dazu sucht der SAP Web Dispatcher in der Liste der Logon-Gruppen, ob eine Logon-Gruppe definiert ist. Falls eine gefunden wird, so muss innerhalb dieser der Lastausgleich durchgeführt werden.

Achtung

Da bei HTTP mit sehr vielen Requests zu rechnen ist, muss diese Logon-Gruppe das Attribute ‚externer RFC’ besitzen, damit kein Server mit Requests überflutet wird.

Lastausgleich in der ermittelten Servergruppe

Zunächst wird jedem Applikationsserver eine Kapazität zugeordnet. Diese richtet sich beim SAP Web AS ABAP-Server nach der Anzahl der Dialog-Workprozesse. Beim SAP J2EE Application Server wird die Kapazität auf entsprechend ähnliche Weise ermittelt. Die Requests werden dann reihum an die Server verteilt, wobei noch entsprechend der Kapazität gewichtet wird: Hat Server A die doppelte Kapazität von Server B, so erhält A doppelt so viele Requests wie B.

Serverauswahl und Lastausgleich für HTTPS-Requests

Da bei HTTPS-Requests der SAP Web Dispatcher die URL nicht lesen kann, kann er HTTPS-Requests nur reihum an die HTTPS-fähigen Server des Systems verteilen. Hierbei wird wie oben beschrieben die Kapazität der Server berücksichtigt. Um J2EE-Requests bearbeiten zu können, muss jeder HTTPS-fähige Server den J2EE-Server integriert haben.

Der ICM des Servers, der den HTTPS-Request erhält, kann die URL entschlüsseln und dann entscheiden, ob der Request an das ICF oder an den integrierten J2EE-Server gehen soll.

Siehe auch:

SAP Web Dispatcher und SSL