Show TOC

HTTP-Lastverteilung durch den SAP Message-ServerLocate this document in the navigation structure

Voraussetzungen

Empfehlung

SAP empfiehlt, als Einstiegspunkt für Ihre Webanfragen den SAP Web Dispatcher einzusetzen. Dieser dient dann als Zugangspunkt für Ihr Netz und führt auch die Lastverteilung für HTTP-Requests durch.

Beachten Sie dazu SAP-Hinweis 1040325 Auf SAP-Site veröffentlichte Informationen.

Achtung

Sie können die HTTP-Lastverteilung durch den SAP Message-Server nur für stateless Anwendungen verwenden. Der Message Server kann weder im Portalumfeld, noch als Load Balancer für stateful Anwendungen verwendet werden.

Verwenden Sie stattdessen den SAP Web Dispatcher.

Um den SAP Message-Server für die Lastverteilung in einem SAP-System (AS ABAP) einsetzen zu können, müssen folgende Voraussetzungen erfüllt sein.

  • Bei allen Applikationsservern sind HTTP-Ports eingerichtet, über die der Message-Server die Informationen von den Servern bekommt.

    Hierzu muss der Parameter ms/server_port_<xx> im Profil des Message-Servers gesetzt sein.

    Hinweis

    Sie können die Informationen auch per HTTPS übermitteln. Dann müssen Sie gewährleisten, dass HTTPS-Ports eingerichtet sind und im Profil des Message-Servers folgende Parameter setzen:

    ms/urlmap_secure = 1

    ms/urlprefix_secure = 1

  • Die folgenden ICF-Services müssen aktiviert sein (Transaktion SICF).

    /default_host/sap/public/icf_info

    /default_host/sap/public/icf_info/logon_groups

    / default_host/sap/public/icf_info/urlprefix

  • Sie können nicht mit zusätzlichen virtuellen Hosts arbeiten, wenn Sie die HTTP-Lastverteilung durch den Message-Server verwenden wollen.

Kontext

Vorgehensweise

  • Funktionsweise

    Ein SAP-System besteht in der Regel aus vielen Applikationsservern, die sich die Last teilen.

    Die Lastverteilung wird vom Message-Server (es gibt genau einen Message-Server im SAP-System) durchgeführt: bei der Anmeldung wird der Benutzer vom Message-Server dem Applikationsserver zugeteilt, der gerade die geringste Last hat. Dieses Verfahren wird auch für eingehende HTTP-Requests angewandt.

    Jeder Applikationsserver, der an der Lastverteilung teilnimmt, teilt dem Message-Server mit, wie viele Workprozesse er bereitstellt und ob er HTTPS-Verbindungen akzeptiert. Beim Start verbindet sich also ein Client aus dem Internet zunächst mit dem (auch HTTP-fähigen) Message-Server; dieser teilt ihm dann per Redirect mit, mit welchem Applikationsserver der Client sich verbinden soll. Natürlich werden HTTPS-Requests nur an Applikationsserver vergeben, die HTTPS-Anfragen akzeptieren.

  • Konfiguration

    Damit dieses Verfahren funktioniert, muss der Message-Server einen oder mehrere zusätzliche Ports öffnen. Hierzu verwenden Sie folgenden Profilparameter:

    ms/server_port_<xx>

    Damit spezifizieren Sie die HTTP(S)-Ports, die der Message-Server zusätzlich öffnet, um HTTP(S)-Requests weiterzuleiten (REDIRECT).

    Für HTTPS müssen noch zusätzliche SSL-Parameter gesetzt werden, um SSL einsetzen zu können. Außerdem muss der Message-Server als Multi-Threaded-Programm ablaufen, da jeder HTTPS-Request in einem eigenen Thread bearbeitet wird.

    Sie können im Message-Server-Monitor (Transaktion SMMS) dynamisch Ports (Services) hinzufügen oder löschen.

    Die veralteten Parameter ms/http_port und ms/https_port funktionieren noch aus Kompatibilitätsgründen, sollten aber nicht mehr verwendet werden.

    Achtung

    Wenn Sie den SAP Web Dispatcher verwenden, beachten Sie, dass Sie die Parameter ms/http_port und ms/https_port im Profil des Web Dispatchers benötigen, damit der Web Dispatcher die Verbindung zum Message-Server aufbauen kann.

    Es gibt noch folgende weitere Parameter, die jedoch mit passenden Defaultwerten vorbelegt sind.

    • ms/http_max_ports: maximale Anzahl von HTTP-Ports, die der Message-Server zusätzlich aufmachen kann. Default ist 20.

    • ms/http_max_clients: maximale Anzahl von HTTP-Clients, die sich parallel am Message-Server anmelden können. Default ist 1000.

    • ms/http_timeout: Timeout für Netzwerk-Operationen: wenn in dieser Zeitspanne keine weiteren Aktionen erfolgen, wird die Verbindung zum HTTP-Client unterbrochen. Die Angabe des Timeout erfolgt in Sekunden. Default ist 20.

    • ms/http_bufferln: maximale Länge eines HTTP-Headers, der eingelesen werden kann. Die Angabe erfolgt ein Bytes. Default ist 65636.

    Achtung

    Bei der Verwendung von SSL müssen die SSL-Parameter richtig gesetzt sein (siehe SSL-Dokumentation).

  • Arbeiten mit Logon-Groppen

    Falls für die eintreffende URL eine Logon-Gruppe (Pflege in der Transaktion SMLG) definiert ist, sucht der Message-Server in der Liste der Logon-Gruppen, ob diese Logon-Gruppe definiert ist. In dieser Gruppe führt er dann den Lastausgleich durch.

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