
Es stehen verschiedene Möglichkeiten zur Verfügung, den SAP Web Dispatcher hochverfügbar zu machen.
Hochverfügbarkeit auf Prozessebene (auf dem selben Rechner)
Hochverfügbarkeit mit Standby-Web-Dispatcher (mit HA-Lösung)
Hochverfügbarkeit durch mehrere parallele Web Dispatcher
Hochverfügbarkeit auf Prozessebene
Sie können den SAP Web Dispatcher auf Prozessebene hochverfügbar machen und sich damit gegen für Software-Fehler schützen. Dieses Verfahren hilft nicht gegen den Absturz der gesamten Maschine.
RESTART-Option im Profil
Mit dem RESTART -Kommando im Instanzprofil können Sie erreichen, dass der Prozess nach einem Absturz vom Start Service neu gestartet wird.
Fügen Sie dazu die Neustart-Zeile für das Programm ins Instanzprofil ein, z.B.
Restart_Program_00 = local sapwebdisp pf=$(DIR_PROFILE)/BIN_WD77
Diese Möglichkeit steht auf allen Plattformen zur Verfügung, allerdings nur, wenn der SAP Web Dispatcher vom Start Service sapstartsrv gestartet wurde.
Startoption -auto-restart
Auf UNIX-Plattformen steht Ihnen auch die Option -auto_restart beim Start des Web Dispatchers zur Verfügung. Dann verhält sich der Web Dispatcher wie folgt:
Die benötigten Ressourcen (Shared Memories, Sockets, Verwaltungsstrukturen) des SAP Web Dispatchers werden beim Start geladen.
Anschließend wird dieser Prozess durch den Systemaufruf fork() dupliziert, d.h. es gibt nun zwei Prozesse, die genau dieselben Shared Memories, Sockets und Verwaltungsstrukturen kennen. Der Ursprungsprozess (Vaterprozess V ) übernimmt dann die Überwachungsfunktion (Watchdog), während der neue Prozess (Kindprozess K ) die eigentlichen Aufgaben des SAP Web Dispatchers (Weiterleiten der Requests, Loadbalancing,...) wahrnimmt.
Der Überwachungsprozess V prüft dann alle n Sekunden den Zustand des SAP Web Dispatcher-Prozesses K.
Wenn sich der Prozess K beendet (gewünscht oder unerwartet), wird dies vom Watchdog V erkannt und der nach dem Start eingefrorene Zustand des Prozesses wird erneut dupliziert ( fork).
Dies bietet folgende Vorteile:
Schnelle Wiederverfügbarkeit des SAP Web Dispatchers, weil die Ressourcen nicht neu angelegt werden müssen
„Zero Downtime“ , weil Requests an den SAP Web Dispatcher nicht verloren gehen, sondern in der Systemqueue zwischengespeichert werden und nach dem Duplizieren des Prozesses vom SAP Web Dispatcher-Arbeitsprozess (K) prozessiert werden können. Requests, die im Moment des Absturzes gerade bearbeitet wurden, gehen natürlich verloren.
Einschränkungen für Betriebssysteme
Die Option -auto_restart wird unter z/OS und Windows nicht unterstützt!
Beenden des hochverfügbaren SAP Web Dispatchers
Wenn Sie den SAP Web Dispatcher beenden wollen, müssen Sie darauf achten, dass Sie den Watchdog-Prozess (V) beenden (wenn Sie den anderen Prozess beenden, wird dieser nachgestartet!). Hierzu schicken Sie ein SIGINT an die PID des Watchdogs. Diese können Sie der Trace-Datei dev_webdisp_watchdog entnehmen.
Durch das Beenden des Watchdogs wird der SAP Web Dispatcher-Arbeitsprozess K ebenfalls beendet.
Hochverfügbarkeit des SAP Web Dispatchers mit externer HA-Software
Dabei wird der SAP Web Dispatcher von dieser HA-Software überwacht und nach einem Absturz von dieser wieder neu gestartet (auf einem anderen Rechner).

Dieses Verfahren können Sie in allen Szenarien anwenden:
Szenarien mit SAP NetWeaver Portal
Szenarien ohne SAP NetWeaver Portal
Szenarien mit ROUTER -Protokoll ( End-to-End SSL )
Weitere Informationen:
Microsoft Cluster Service (MSCS) Konfiguration, SAP-Hinweis
834184
Option shm_attach_mode im Abschnitt SAP Web Dispatcher starten .
Hochverfügbarkeit durch parallele Web Dispatcher
Sie können Hochverfügbarkeit auch durch parallele SAP Web Dispatcher erreichen. Beide Web Dispatcher haben die gleiche Konfiguration und leiten ihre Requests an das Zielsystem weiter. Da Stickiness über ein Cookie erreicht wird, kommt ein stateful Request auf jedem Fall zu dem richtigen Applikationsserver.
Dann werden die Requests durch einen Load Balancer auf die Web Dispatcher verteilt. Hierzu können Sie auch DNS-Load-Balancing verwenden.

Szenarien
Sie können in folgenden Szenarien mit parallelen Web Dispatchern arbeiten:
Szenario ohne Enterprise Portal
Web Dispatcher steht vor einem EP-System
Das Verfahren kann in folgenden Szenarien nicht ohne Weiteres verwendet werden:
Web Dispatcher steht vor einen Backend-System mit Anwendungen im Enterprise Portal (vgl. folgendes Beispiel)
Der Web Dispatcher wird mit dem ROUTER -Protokoll betrieben ( End-to-End SSL )
Die Konfiguration paralleler Web Dispatcher mit einem Load Balancer funktioniert in diesen Szenarien dann, wenn der Load Balancer Requests von einem Benutzer (von einer IP-Adresse oder IP-Adressmaske) immer zum gleichen Web Dispatcher weiterleitet.
Sie haben ein Portal-System EP mit einem Web Dispatcher ( WD1) vor den Portal-Servern, der den Lastausgleich für eingehende Requests durchführt.
Im Portal gibt es ein iView, durch das Sie auf eine SAP-Anwendung in einem Backend-System zugreifen können. Das Backend-System besteht auch aus mehreren Instanzen mit einem Web Dispatcher WD2 für den Lastausgleich.
Die Kommunikation mit den verschiedenen Komponenten läuft dann ab wie folgt:
Der Client (Browser) schickt den Request über den Web Dispatcher an das Portalsystem.
In einem iView setzt der Benutzer einen Request ab, der im Backend-System bearbeitet werden muss. Im Portal wird dazu eine URL generiert und an den Client geschickt.
Der Client verwendet diese URL für den nächsten Request und gelangt so über den Web Dispatcher des Backend-Systems WD2 auf eine Instanz des Backend-Systems. Hier wird die Antwort auf den Request erzeugt und dem Client zurückgeschickt.
Damit dieses Verfahren funktioniert, muss der Web Dispatcher vor dem Backend-System ( WD2) einen internen Zustand halten und kann nur durch 2 parallele Web Dispatcher hochverfügbar gemacht werden, wenn ein Externer Load Balancer vor den Web Dispatchern steht, der gewährleistet, dass Requests desselben Benutzers immer zum selben Web Dispatcher geleitet werden.
Die Hochverfügbarkeit auf Prozessebene oder das HA-Setup mit externer Software steht Ihnen ebenfalls zur Verfügung.
Der Web Dispatcher WD1 kann jedoch ohne Einschränkung durch einen parallel geschalteten Web Dispatcher hochverfügbar ausgelegt werden (s.o.).
Die folgende Abbildung stellt diesen Sachverhalt dar.
