Show TOC

Serverauswahl und Lastausgleich durch den SAP Web DispatcherLocate this document in the navigation structure

Verwendung

Der SAP Web Dispatcher leitet jeden eingehenden HTTP(S)-Request an einen geeigneten SAP NetWeaver Application Server zur Bearbeitung weiter wie in der folgenden Grafik dargestellt.

Abbildung 1: Weiterleitung von Requests durch den SAP Web Dispatcher

Hierbei nimmt er folgende Aufgaben wahr:

  • Prüfen der Session-ID, um Folgerequests bei stateful Sessions an den bearbeitenden Server zu geben ( Session-Stickiness)

  • Entscheidung, ob es sich um einen ABAP- (etwa eine BSP-Applikation) oder Java (z.B. eine JSP oder ein Servlet) -Request handelt

  • Lastausgleich

  • HTTPS-Terminierung oder End-to-End SSL

  • URL-Filtering

Prozess

Als Erstes prüft der SAP Web Dispatcher, von welchem Typ der eingegangene Request ist (vgl. Bearbeitung von Administrationsrequests).

Der im Folgenden beschriebene Prozess läuft nur ab, wenn es sich nicht um einen Administrationsrequest handelt.

Die Zuordnung eines HTTP-Requests (oder eines ausgepackten HTTPS-Requests) zu einem Server erfolgt in zwei Stufen. HTTPS-Requests mit End-to-End SSL werden am Schluss des Abschnitts behandelt.

  1. Zunächst ermittelt der SAP Web Dispatcher, ob der eintreffende HTTP-Request an einen ABAP- oder Java-Server weitergeleitet werden soll. Er ermittelt eine Gruppe von Servern im SAP-System, die den Request ausführen können. Die Informationen über die Gruppen bekommt er vom Backend (AS ABAP oder AS Java) oder über eine Datei.

  2. Innerhalb dieser Gruppe wird dann ein Lastausgleich durchgeführt. Wenn entschieden ist, an welchen Server der Request gehen soll, leitet der SAP Web Dispatcher ihn an den ICM des entsprechenden Applikationsservers.

Ermitteln der Servergruppe

Wie der SAP Web Dispatcher die Servergruppe bestimmt, die den Request bearbeiten soll, ist unter Ermitteln der Servergruppe beschrieben.

Arbeiten mit Logongruppen im SAP-System

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

Lastausgleich in der ermittelten Servergruppe

Beim Lastausgleich durch den SAP Web Dispatcher kommen sowohl statische als auch dynamische Elemente zum Einsatz. Der Web Dispatcher bietet verschiedene Verfahren für den Lastausgleich an. Eine wichtige Größe in diesem Zusammenhang ist die Kapazität eines Applikationsservers. Sie ist ein Maß für die "Stärke" eines Applikationsservers.

Welches Verfahren für Ihre Anwendung am besten ist, hängt von vielen Faktoren ab. Im Normalfall führt das Standardverfahren (gewichtetes Round-Robin) zu einer ausgewogenen Lastverteilung. Falls Sie den Verdacht haben, dass ein anderes Verfahren die Lastverteilung verbessert, können Sie dies mit dem Parameter wdisp/load_balancing_strategy steuern.

Folgende Verfahren zum Lastausgleich sind konfigurierbar.

Einfaches gewichtetes Round Robin

Parameterwert: simple_weighted_round_robin

Jeder Server mit Kapazität k erhält genau k aufeinander folgende Requests, bevor der nächste Server an der Reihe ist. Die Requests werden also reihum ( "round robin") an die Instanzen verteilt, wobei 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.

Dieses Verfahren ist einfach und deterministisch, da es keine dynamischen Elemente enthält.

Hinweis

Dieses Verfahren kann insbesondere bei End-to-End SSL zu unerwarteten Ergebnissen führen, wenn einzelne Server zu viele unmittelbar aufeinander folgende Anfragen erhalten.

Dynamisches gewichtetes Round Robin

Parameterwert: weighted_round_robin (Default)

Die Lastverteilung geschieht anhand der geschätzten Momentanauslastung ( "Load-Faktors"). Der Server mit dem niedrigsten Load-Faktor erhält den nächsten Request. Wird einem Server ein Request zugeteilt, so wird der Load-Faktor proportional zum Kehrwert der Kapazität dieses Servers erhöht. Der Load-Faktor ist aus der Web-Administrations-Oberfläche ersichtlich. Da sich der Load-Faktor ständig verändert, ist die Angabe des next preferred server in der Admin-Oberfläche lediglich eine Momentaufnahme.

Das Verfahren bietet den Vorteil, dass die Serverauslastung sehr gut ist, insbesondere bei End-to-End SSL.

Das Verfahren enthält noch ein dynamisches Element: Der Web Dispatcher kennt für jeden Applikationsserver die Anzahl der Requests, die dieser noch zur Bearbeitung hat. Diese Information fließt ebenfalls in die Serverauswahl ein.

Volldynamische Lastverteilung anhand von Server-Antwortzeiten

Parameterwert: adaptive

Zur Schätzung der Momentanauslastung (Bestimmung des "Load-Faktors") eines Servers werden (anstelle fest vorgegebener Kapazitätswerte) die tatsächlichen Antwortzeiten auf die periodisch an jeden Server versandten "ping"-Anfragen berücksichtigt. Je kleiner die Antwortzeit (in Millisekunden), desto weniger stark wird der aktuelle Load-Faktor bei jedem Request inkrementiert.

Serverauswahl und Lastausgleich für HTTPS-Requests

Da bei HTTPS-Requests mit End-to-End SSL 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 Java-Requests bearbeiten zu können, muss jeder HTTPS-fähige Server den AS Java integriert haben. Der ICM des Servers, der den HTTPS-Request erhält, kann die URL entschlüsseln und dann entscheiden, ob der Request an den AS ABAP oder den AS Java gehen soll.

Weitere Informationen