Das vollständige WebSphere Product Center-System besteht aus folgenden, gleichzeitig ausgeführten Services:
admin Der Verwaltungsserver startet/stoppt Module auf fernen Maschinen. appsvr Der Anwendungsserver führt Aktionen für Java Server Pages aus. eventprocessor Der Ereignisprozessor teilt Ereignisse zwischen allen Modulen zu. queuemanager Der Warteschlangenmanager sendet Dokumente außerhalb von WebSphere Product Center. scheduler Die Planungsfunktion führt Jobs im Hintergrund aus. workflow Die Workflow-Engine. admin_properties.xml und Clustering
Services können in einem Cluster von Workstations ausgeführt werden. Die verschiedenen Maschinen in dem Cluster werden in der Datei admin_properties.xml definiert:
$TOP/etc/default/admin_properties.xml
Hinweis:: Weitere Informationen finden Sie in der Datei 'admin_properties.xml'. Jeder Service kann auf allen in der Datei 'admin_properties.xml' aufgelisteten Maschinen aufgeführt werden.
Ein typischer WebSphere Product Center-Cluster kann den Anwendungsserver und das Unterstützungsdienstprogramm des RMI-Registers (RMI Registry) auf dem WebSphere Product Center-Server sowie die übrigen WebSphere Product Center-Komponenten auf dem sekundären Server enthalten.
Im Fall einer Überbrückung durch den primären Server könnten die Services, die zuvor nicht auf dem sekundären Server ausgeführt wurden, mit minimalem Aufwand wieder online bereitgestellt und dabei die Ausfallzeit minimiert werden.
Abbildung 4 - Typischer WebSphere Product Center-Cluster
Servicename - langer und kurzer Name
Jeder Service wird eindeutig durch einen Servicenamen identifiziert. Der Servicename muss eindeutig sein (ein Service wird nicht gestartet, wenn ein anderer Service mit demselben Namen auf einer Maschine in dem Cluster ausgeführt wird.)
Jeder Service kann auf mehreren Maschinen ausgeführt werden, solange der Servicename jeweils unterschiedlich ist.
Die Namen für die Services 'admin' und 'appsvr' werden vom System festgelegt.
admin_<maschinenname> für admin (ex: 'admin_server1')
appsvr_<maschinenname> für appsvr (ex: 'appsvr_server1')
Wählen Sie für die anderen Services einen beliebigen Namen aus. Der ausgewählte Name ist der Kurzname des Service.
Intern wird ein ausgeschriebener Name unter Verwendung dieses Kurznamens erstellt:
rmi://<maschinenname>:<rmi-port>/<db-benutzername>/<servicetyp>/<kurzname_des_service>
Beispiel:
Wenn Sie einen Service 'scheduler' auf einer Maschine 'server1' ausführen, den RMI-Port 17507 verwenden, eine Verbindung zu einem Datenbankbenutzer 'pauadm' herstellen und den Service 'sch1' nennen, dann lautet der ausgeschriebene Name:
rmi://server1:17507/pauadm/scheduler/sch1
Wenn eine andere Planungsfunktion (sch2) auf einer Maschine 'server 2' für denselben Benutzer und Port ausgeführt wird, lautet der ausgeschriebene Name:
rmi://server2:17507/pauadm/scheduler/sch2
Speichermarkierungen für Servicetypen definieren
Speichermarkierungen für verschiedene WebSphere Product Center-Services sind im Initialisierungsscript von WebSphere Product Center definiert. Dieses befindet sich im WebSphere Product Center-Installationsverzeichnis.
<installationsverzeichnis>/setup/init_ccd_vars.sh
Es empfiehlt sich, die folgende Einstellungen der Speichermarkierungen für die WebSphere Product Center-Services zu verwenden:
export ADMIN_MEMORY_FLAG='-Xmx64m -Xms48m'
export APPSVR_MEMORY_FLAG='-Xmx512m -Xms64m'
export EVENTPROCESSOR_MEMORY_FLAG='-Xmx64m -Xms48m'
export QUEUEMANAGER_MEMORY_FLAG='-Xmx64m -Xms48m'
export SCHEDULER_MEMORY_FLAG='-Xmx1024m -Xms48m'
export WORKFLOWENGINE_MEMORY_FLAG='-Xmx64m -Xms48m'
RMI – Remote Method Invocation (Aufruf ferner Methoden)
Die Serviceregistrierung wird über RMI (Java Remote Method Invocation, Java-Aufruf ferner Methoden) ausgeführt. Stellen Sie vor dem Ausführen von Services sicher, dass RMI auf der Maschine gestartet wurde.
RMI-Status
Um eine Liste aller ausgeführten Services in einem Cluster abzurufen, führen Sie folgendes Script aus:
$TOP/bin/go/rmi_status.sh
Dieses Script kontaktiert den RMI-Dämon auf allen Maschinen im Cluster und ruft eine Liste der lokalen Services auf jeder Maschine ab. Es gibt eine Liste mit ausgeschriebenen Namen zurück.
Protokolldateien
Jeder Service generiert eine Laufzeitprotokolldatei.
$TOP/logs/<service>/<servicename>/svc.out
Beispiel:
Eine Planungsfunktion namens 'sch1' generiert eine Laufzeitprotokolldatei svc.out im Verzeichnis $TOP/logs/scheduler/sch1.
Es wird empfohlen, nach dem Starten eines Service die Protokolldatei zu überprüfen, um sicherzustellen, dass alles ohne Probleme gestartet wurde.
Service starten
In den folgenden Abschnitten wird beschrieben, wie die Services mit Hilfe von lokalen Scripts gesteuert werden. Bevor ein Service verwendet werden kann, muss das RMI-Register auf der Maschine gestartet werden, die den Service verwenden soll.
Um RMI zu starten, führen Sie folgendes Script aus:
$TOP/bin/go/start/start_rmiregistry.sh
Service auf der lokalen Maschine starten
Die einfachste Art, einen Service auf der lokalen Maschine zu starten, ist die Verwendung der Scripts im Verzeichnis $TOP/bin/go/start/
Script Beschreibung start_admin.sh
Startet den Verwaltungsservice.
start_appsvr.sh
Startet dem Anwendungsserver.
start_eventprocessor.sh
Startet den Ereignisprozessor.
start_queuemanager.sh
Startet den Warteschlangenmanager.
start_rmiregistry.sh
Startet das RMI-Register.
start_scheduler.sh
Startet die Planungsfunktion.
start_workflowengine.sh
Startet die Workflow-Engine.
Jedes dieser Scripts (außer start_admin.sh, start_appsvr.sh und start_rmiregistry.sh) kann den Servicenamen als optionales Argument aufnehmen:
-svc_name=<servicename>
Die Services 'admin' und 'appsvr' verwenden einen Standardnamen (admin_<maschinenname> und appsvr_<maschinenname>). Die Angabe eines anderen Namens bleibt ohne Wirkung.
Wird kein Servicename angegeben, wird ein Standardname verwendet:
"scheduler" für die Planungsfunktion
"eventprocessor" für den Ereignisprozessor
"queuemanager" für den Warteschlangenmanager
"workflow" für den Workflow-Engine
Hinweis: Wird ein lokaler Service mit dem Namen eines anderen, bereits ausgeführten lokalen Service gestartet, wird der erste lokale Service auch zuerst abgebrochen. Daher können die Scripts auch zum 'Neustart' (erst abbrechen, dann erneut starten) eines Service verwendet werden.
Beispiel:
Starten der Planungsfunktion mit dem Namen "sch1":
$TOP/bin/go/start/start_scheduler.sh -svc_name=sch1
Starten der Planungsfunktion mit dem Standardnamen:
$TOP/bin/go/start/start_scheduler.sh
Service abbrechen
Durch das Abbrechen eines Service wird dieser beendet und ist nicht mehr verfügbar.
Wenn die Planungsfunktion beispielsweise einen Job ausführt, wird dieser Job mitten in der Verarbeitung abgebrochen.
Service auf der lokalen Maschine abbrechen
Diese Struktur spiegelt die Startstruktur wieder.
Verwenden Sie die Scripts im Verzeichnis $TOP/bin/go/abort/
Script Beschreibung abort_admin.sh
Bricht den Verwaltungsservice ab.
abort_appsvr.sh
Bricht den Anwendungsserver ab.
abort_eventprocessor.sh
Bricht den Ereignisprozessor ab.
abort_queuemanager.sh
Bricht den Warteschlangenmanager ab.
abort_rmiregistry.sh
Bricht das RMI-Register ab.
abort_scheduler.sh
Bricht die Planungsfunktion ab.
abort_workflowengine.sh
Bricht die Workflow-Engine ab.
Jedes dieser Scripts (außer abort_admin.sh, abort_appsvr.sh und abort_rmiregistry.sh) kann den Servicenamen als optionales Argument aufnehmen:
-svc_name=<servicename>
Hinweis: Wird RMI abgebrochen, ist es nicht mehr möglich, auf Services auf fernen Maschinen zuzugreifen.
Service stoppen
Beim Stoppen eines Service erhält dieser die Anforderung, sich ordnungsgemäß abzuschalten. Ist der Service "blockiert", führt er die Prozedur zum Beenden unter Umständen gar nicht aus. Die Planungsfunktion stoppt dann nicht, bis alle aktuell ausgeführten Jobs fertig gestellt sind.
Service auf der lokalen Maschine stoppen
Diese Struktur spiegelt die Startstruktur wieder.
Verwenden Sie die Scripts im Verzeichnis $TOP/bin/go/stop/
Script Beschreibung stop_admin.sh
Stoppt den Verwaltungsservice.
stop_appsvr.sh
Stoppt dem Anwendungsserver.
stop_eventprocessor.sh
Stoppt den Ereignisprozessor.
stop_queuemanager.sh
Stoppt den Warteschlangenmanager.
stop_scheduler.sh
Stoppt die Planungsfunktion.
stop_workflowengine.sh
Stoppt die Workflow-Engine.
Jedes dieser Scripts (außer abort_admin.sh, abort_appsvr.sh und abort_rmiregistry.sh) kann den Servicenamen als optionales Argument aufnehmen:
-svc_name=<servicename>
Wichtiger Hinweis zu Abbrechen und Stoppen
Soll Stoppen oder Abbrechen verwendet werden?
Abbrechen Garantiert, dass der Service beendet wird. Eine aktuell ausgeführte Task wird jedoch unter Umständen unterbrochen. Stoppen Garantiert, dass falls der Service gestoppt wird, dies ordnungsgemäß nach dem vorherigen Stoppen aller aktuell ausgeführten Tasks erfolgt. Alle WebSphere Product Center-Module starten
WebSphere Product Center auf der lokalen Maschine starten
Führen Sie das Script $TOP/bin/go/start/start_local.sh aus.
Damit werden das RMI-Register sowie die folgenden Services gestartet:
- Verwaltung namens 'admin_<maschinenname>'
- Anwendungsserver namens 'appsvr_<maschinenname>'
- Ereignisprozessor namens 'eventprocessor'
- Warteschlangenmanager namens 'queuemanager'
- Planungsfunktion namens 'scheduler'
- Ablauf namens 'workflow'
Hinweis: Zuerst wird versucht, ein unter Umständen auf der lokalen Maschine vorhandenes System abzubrechen, bevor ein neuer Vorgang gestartet wird.
WebSphere Product Center auf der lokalen Maschine abbrechen
Führen Sie das Script $TOP/bin/go/abort/abort_local.sh aus.
Alle auf der lokalen Maschine gestarteten Services werden abgebrochen. Das RMI-Register wird abgebrochen.
WebSphere Product Center auf der lokalen Maschine stoppen
Führen Sie das Script $TOP/bin/go/stop/stop_local.sh aus.
Alle auf der lokalen Maschine gestarteten Services werden gestoppt. Das RMI-Register wird standardmäßig mit den anderen Services gestoppt. Um das RMI-Register aktiv zu halten, übergeben Sie die folgende Option:
--kill_rmi=no
Hinweis:: Vor "kill_rmi=no" stehen zwei Bindestriche.
Servicestatus
Kurzstatus eines Service abrufen
Um den Kurzstatus eines Services abzurufen, übergeben Sie die folgenden Parameter:
-cmd=check -svc=<servicename>
Beispiel:
Status der Planungsfunktion abrufen:
rootadmin.sh -cmd=check -svc=scheduler
Der Kurzstatus kann einen der folgenden Werte annehmen:
running (aktiv)
Der Service ist aktiv und antwortet auf eine "Überwachungssignalfunktion".
not found (nicht gefunden)
Der Service wurde nicht gefunden. Möglicherweise wurde der Service nicht gestartet, oder er ist abgestürzt.
found but not responding (gefunden, aber ohne Antwort)
Der Service wurde gefunden und ist im RMI-Register eingetragen, er antwortet jedoch nicht auf die "Überwachungssignalfunktion". Der Service muss unter Umständen erneut gestartet werden.
Ausführlichen Status eines Service abrufen
Um den ausführlichen Status eines Service abzurufen, übergeben Sie die folgenden Parameter:
-cmd=status -svc=<servicename>
Dadurch wird eine HTML-Datei erstellt, die mit jedem Browser angezeigt werden kann. Auf einem Terminal können Sie LYNX zum Formatieren der Ausgabe verwenden.
Beispiel:
Status der Planungsfunktion (Scheduler) abrufen:
rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx /tmp/sch_status.html
ODER
rootadmin.sh -cmd=status -svc=scheduler > /tmp/sch_status.html; lynx -dump /tmp/sch_status.html
Hinweis:: Die im vorstehenden Beispiel verwendeten ">" übertragen die Statusdetails an eine Dateiausgabeadresse.
Der Status bietet eine Übersicht über die verschiedenen Threads, die in dem Service ausgeführt werden und zeigt den Status der aktuell durch den Service belegten Datenbankverbindungen an.