Bei der Konfiguration eines Konfigurationsdateisystems für
WebSphere Application
Server for z/OS müssen Sie mehrere
Planungsentscheidungen treffen.
Zellen-, Knoten- und Servereinstellungen werden wie die implementierten Anwendungen im
Konfigurationsdateisystem von WebSphere Application
Server for z/OS gespeichert.
Als Konfigurationsdateisystem können Sie
ein ZFS-Dateisystem (zSeries File System) oder ein HFS-Dateisystem (Hierarchical
File System) verwenden.
Tipp: Ab WebSphere Application
Server for z/OS Version 7.0 sind die SBBOLOAD- und SBBOLD2-Datensätze
nicht mehr vorhanden.
Der Grund hierfür ist, dass sich die Lademodule jetzt im Produktdateisystem befinden.
Wenn Sie eine Konfiguration von der Verwendung von Lademodulen im Produktdateisystem
auf die Verwendung von Lademodulen in einer Datei umstellen möchten, können Sie das im Artikel
Befehl switchModules beschriebene Tool verwenden. Seit WebSphere
Application Server for z/OS Version 8.0 muss die Umgebungsvariable
server_dlls_in_hfs für den Server
auf
0 gesetzt sein, um die DLLs, die in einen Datensatz in STEPLIB,
LPA oder eine Linkliste gestellt wurden, zu verwenden. Damit der Dämon die DLLs berücksichtigt,
muss
WAS_DAEMON_ONLY_server_dlls_in_hfs auf Zellenebene definiert werden.
Jeder Knoten benötigt ein Ausgangsverzeichnis
Jeder Knoten in WebSphere Application
Server for z/OS,
sei es ein eigenständiger Anwendungsserver,
ein Deployment Manager, ein verwalteter Anwendungsserverknoten oder ein Location Service Daemon,
benötigt ein Ausgangsverzeichnis mit Lese-/Schreibberechtigung, das
manchmal auch als WAS_HOME bezeichnet wird.
Dies ist die Struktur
eines Konfigurationsdateisystems in
WebSphere Application
Server for z/OS,
das an /WebSphere/V9R0 angehängt ist. Es enthält ein WAS-Ausgangsverzeichnis
(WebSphere Application Server)
für einen einzelnen Anwendungsserver mit dem Namen BBOS001 mit einer Zelle und einem Knoten, die beide
den Namen SYSA haben.
/WebSphere/V9R0
/AppServer
/bin
/classes
/java
/lib
/logs
/profiles
/default -> Dies ist das Profilstammverzeichnis
/temp
...
/Daemon
/config
/SYSA
SYSA.SYSA.BBODMNB -> /WebSphere/V9R0/Daemon/config/SYSA/SYSA/BBODMNB
SYSA.SYSA.BBOS001 ->
/WebSphere/V9R0/AppServer/profiles/default/config/cells/SYSA/nodes/SYSA
/servers/server1
SYSA.SYSA.BBOS001.HOME -> /WebSphere/V9R0/AppServer
Das WAS-Ausgangsverzeichnis
(WebSphere Application
Server) für BBOS001 hat den Namen AppServer. Es enthält
Verzeichnisse mit den gesamten Konfigurationsdaten für den Knoten SYSA und den Server
BBOS001.
Das Verzeichnis
/Daemon enthält Konfigurationsdaten für
die Location Service Daemons, die für die Knoten
in diesem Konfigurationsdateisystem definiert sind.
Anmerkung: Das Unterverzeichnis
/Daemon/config wird nach dem Zellennamen unterteilt.
Wenn die Zellen unterschiedliche Kurznamen haben, werden die
Location-Service-Daemon-Informationen für jede Zelle separat gespeichert.
Das Ausgangsverzeichnis des Dämons hat den unveränderlichen WebSphere Application
Server-Namen
Daemon.
Verwendung symbolischer Verbindungen für den Zugriff auf die Startparameter
Zusätzlich
zu den WebSphere Application Server-Ausgangsverzeichnissen selbst enthält das Konfigurationsdateisystem eine mehrteilige symbolische Verbindung für jeden Server,
die auf die Startparameter für den betreffenden Server verweist.
Der Name der symbolischen Verbindung lautet
Zellenkurzname.Knotenkurzname.Serverkurzname.
Das oben gezeigte
Beispiel eines Konfigurationsdateisystems enthält die symbolische Verbindung SYSA.SYSA.BBODMNB
zum Starten des
Location Service Daemon und die symbolische Verbindung
SYSA.SYSA.BBOS001 zum Starten des Anwendungsservers
BBOS001. Die zweite symbolische Verbindung wird
im Parameter ENV im Befehl START angegeben,
wenn der Server oder der Location
Service Daemon über die
MVS-Konsole gestartet wird:
START procname,JOBNAME=BBOS001,ENV=SYSA.SYSA.BBOS001
Jede symbolische Verbindung
verweist auf das Unterverzeichnis, in dem die Datei was.env des Servers enthalten ist.
Diese Datei enthält die erforderlichen Informationen zum Starten des Servers.
Anmerkung: Während der weiter unten beschriebenen Verarbeitung nach Installationsabschluss muss die Server-JCL das WebSphere Application
Server-Ausgangsverzeichnis selbst anstatt die Speicherposition der Datei was.env
angeben. Dies ist der Zweck der oben gezeigten symbolischen Verbindung
SYSA.SYSA.BBOS001.HOME.
Gemeinsame Verwendung des Konfigurationsdateisystems durch mehrere Zellen
Zwei oder
mehr Zellen in WebSphere Application
Server for z/OS
(eigenständiger Anwendungsserver und/oder
Network Deployment) können ein Konfigurationsdateisystem in
WebSphere Application
Server for z/OS
gemeinsam verwenden, wenn die folgenden Voraussetzungen erfüllt werden:
- Bei der Konfiguration aller Zellen, die das Konfigurationsdateisystem verwenden, müssen dieselben allgemeinen Gruppen
und Benutzer verwendet werden.
Insbesondere muss jede Zelle dieselbe Administratorbenutzer-ID und dieselbe Konfigurationsgruppe verwenden.
- Die Zellen müssen eindeutige Zellenkurznamen verwenden.
- Jeder Knoten muss über ein eigenes
WAS_HOME-Verzeichnis verfügen, das von keinem anderen Knoten und von einer anderen Zelle verwendet wird.
Wie oben erwähnt, kann das
Ausgangsverzeichnis des Dämons
(/Daemon)) von mehreren Zellen gemeinsam verwendet werden,
weil es weiter unten in seiner Verzeichnisstruktur Unterverzeichnisse für jede Zelle im Konfigurationsdateisystem
enthält.
Anmerkung: Beachten Sie, dass die gemeinsame Verwendung eines Konfigurationsdateisystems durch mehrere Zellen
die Wahrscheinlichkeit erhöht, dass durch Probleme mit
einer einzelnen Zelle auch Probleme bei anderen Zellen in demselben Konfigurationsdateisystem auftreten.
Gemeinsame Verwendung des Konfigurationsdateisystems durch mehrere Systeme
Zwei oder mehr
z/OS-Systeme können ein Konfigurationsdateisystem gemeinsam verwenden, sofern
die z/OS-Systeme ein gemeinsames Dateisystem verwenden und das Konfigurationsdateisystem
mit Lese-/Schreibzugriff angehängt ist. Alle Aktualisierungen werden von dem
z/OS-System ausgeführt,
das "Eigner" des Mountpunktes ist.
Für eine Network-Deployment-Zelle ist dies normalerweise das
z/OS-System, auf dem der Deployment Manager der Zelle konfiguriert ist.
Einen Mountpunkt für das Konfigurationsdateisystem in
WebSphere Application Server für z/OS wählen
Die Wahl der Mountpunkte für das Konfigurationsdateisystem in WebSphere Application Server für z/OS ist abhängig von Ihrem
z/OS-Systemlayout, von der Art der zugehörigen
Anwendungsserverumgebungen und von der relativen Bedeutung mehrerer Faktoren:
Konfigurationsaufwand, Verwaltungsaufwand, Leistung, Wiederherstellbarkeit und
ununterbrochene Verfügbarkeit.
- In einem einzelnen z/OS-System:
Wenn Sie WebSphere Application
Server for z/OS auf einem
einzelnen z/OS-System ausführen,
stehen Ihnen eine Vielzahl von Möglichkeiten bei der Auswahl eines Mountpunktes für das
z/OS-Konfigurationsdateisystem zur Verfügung.
Möglicherweise möchten Sie mehrere eigenständige Anwendungsserver in ein
einzelnes Konfigurationsdateisystem aufnehmen, wobei für einen Produktionsserver oder eine Network-Deployment-Zelle
ein separates Konfigurationsdateisystem verwendet wird.
Die Verwendung separater Konfigurationsdateisystemdateien
erhöht die Leistung und die Zuverlässigkeit, während die Verwendung eines
gemeinsamen Konfigurationsdateisystems die Anzahl der benötigten katalogisierten Prozeduren für
Anwendungsserver reduziert.
Beispielsweise könnten Sie ein Konfigurationsdateisystem für die Entwicklungs-, Test- und Qualitätssicherungsserver
verwenden, die alle zu
denselben allgemeinen Gruppen und Benutzern gehören:
/WebSphere/V9R0_test
/DevServer - Ausgangsverzeichnis für die eigenständige Serverzelle DVCELL mit Server DVSR01A
/TestServer1 - Ausgangsverzeichnis für die eigenständige Serverzelle T1CELL mit Server T1SR01A
/TestServer2 - Ausgangsverzeichnis für die eigenständige Serverzelle T2CELL mit Server T2SR01A
/QAServer - Ausgangsverzeichnis für die Network-Deployment-Zelle QACELL mit Deployment Manager QADMGR und Server QVSR01A
Außerdem könnten Sie
ein separates Konfigurationsdateisystem für Ihre Produktionszelle verwenden:
/WebSphere/V9R0_prod
/CorpServer1 - Ausgangsverzeichnis für die Network-Deployment-Zelle
CSCELL mit Deployment Manager CSDMGR und Server CSSR01A
- In einem z/OS-Mehrsystem-Sysplex
ohne gemeinsam genutztes Dateisystem:
In einem Mehrsystem-Sysplex ohne gemeinsam genutztes Dateisystem
muss jedes z/OS-System seine eigenen Konfigurationssystemdateien haben.
Für eigenständige Anwendungsserver und für
Network-Deployment-Zellen, die nicht systemübergreifend sind, gelten dieselben Optionen wie
für ein einzelnes z/OS-System.
- Für systemübergreifende Network-Deployment-Zellen:
In diesem Fall haben Sie zwei
Optionen:
- Sie können auf jedem System einen anderen Mountpunkt für die Konfigurationsdateisystemdateien
der Zelle verwenden.
In diesem Fall können Sie Knoten auf einfache Weise zwischen den Systemen verschieben
(z. B. falls ein System funktionsunfähig wird oder aufgerüstet wird),
weil jeder Mountpunkt auf keinem der anderen Systeme im Systemkomplex verwendet wird,
so dass die Datensätze des Konfigurationsdateisystems eines fehlgeschlagenen Systems an ein alternatives
System im Systemkomplex angehängt werden können.
Beispielsweise könnte auf dem System
LPAR1 ein Konfigurationsdateisystem für einen Teil einer Zelle gespeichert sein:
/var/WebSphere/V9R0config1
/DeploymentManager - Ausgangsverzeichnis für Deployment Manager F1DMGR in Zelle F1CELL
/AppServer1 - Ausgangsverzeichnis für Knoten F1NODEA und die Server F1SR01A und F1SR02A
Ein zweites
Konfigurationsdateisystem könnte auf LPAR2 gespeichert sein:
/var/WebSphere/V9R0config2
/AppServer2 - Ausgangsverzeichnis für Knoten F1NODEB und die Server F1SR02B (Teil eines Clusters) und F1SR03B
Diese Konfiguration
hat den Vorteil, dass Sie den Deployment Manager und den Knoten
F1NODEA nach LPAR2 verschieben können oder
den Knoten F1NODEB nach LPAR1. Der Nachteil dieser Konfiguration liegt darin,
dass F1NODEA und F1NODEB separate Gruppen mit katalogisierten Prozeduren benötigen.
- Alternativ dazu können Sie denselben Mountpunkt für alle
Konfigurationsdateisystemdateien in einer bestimmten Zelle verwenden.
Auf diese Weise können Sie gemeinsame katalogisierte Prozeduren verwenden und ähnliche
Systeme erzielen.
Bei Verwendung derselben Zellenkonfiguration wie oben würde
der Knoten LPAR1 über ein Konfigurationsdateisystem verfügen:
/var/WebSphere/V9R0F1
/DeploymentManager - Ausgangsverzeichnis für Deployment Manager F1DMGR in Zelle F1CELL
/AppServer1 - Ausgangsverzeichnis für Knoten F1NODEA und die Server F1SR01A und F1SR02A
LPAR2 würde über
ein separates Dateisystem an demselben Mountpunkt verfügen:
/var/WebSphere/V9R0F1
/AppServer2 - Ausgangsverzeichnis für Knoten F1NODEB und die Server F1SR02B (Teil eines Clusters) und F1SR03B
Allerdings müsste
im Fall einer Verschiebung
eines dieser LPAR-Knoten auf ein anderes System eine Kopie des einen
Konfigurationssystems in das andere Konfigurationsdateisystem
aufgenommen werden.
- In einem z/OS-Mehrsystem-Sysplex
mit gemeinsam genutztem Dateisystem:
Falls der Systemkomplex ein gemeinsames HFS verwendet,
können Sie für die gesamte Zelle einfach ein großes Konfigurationsdateisystem anhängen.
Geben Sie bei Verwendung des Profile Management Tool oder des Befehls zpmt auf jedem System den
gemeinsamen Mountpunkt für das Konfigurationsdateisystem an.
Wie oben erwähnt, sollten Sie das Konfigurationsdateisystem auf dem z/OS-System, auf dem sich der
Deployment Manager befindet, aktualisieren.
Die Leistung ist abhängig von der Häufigkeit der Konfigurationsänderungen. Sie sollten der Optimierung besondere
Aufmerksamkeit schenken, falls diese Option gewählt wurde.
Alternativ dazu können Sie ein separates Konfigurationsdateisystem an jedes System anhängen,
eventuell unter Verwendung des systemspezifischen Dateisystems, das unter
/&SYSNAME an jedes System angehängt ist:
/LPAR1/WebSphere/V9R0F1
/DeploymentManager - Ausgangsverzeichnis für Deployment Manager F1DMGR in Zelle F1CELL
/AppServer1 - Ausgangsverzeichnis für Knoten F1NODEA und die Server F1SR01A und F1SR02A
/LPAR2/WebSphere/V9R0F1
/AppServer2 - Ausgangsverzeichnis für Knoten F1NODEB und die Server F1SR02B (Teil eines Clusters) und F1SR03B
Jedes System
(LPAR1 und LPAR2) hängt sein eigenes Konfigurationsdateisystem an seinem systemspezifischen Mountpunkt an.
Geben Sie Folgendes an, wenn Sie Profile Management Tool oder den Befehl
zpmt verwenden:
- /LPAR1/WebSphere/V9R0F1 on LPAR1
- /LPAR2/WebSphere/V9R0F1 on LPAR2
Bei Verwendung dieser Option ist die Leistung besser als bei Verwendung eines gemeinsamen
Systemkomplexes. Außerdem ist es möglich, ein Konfigurationsdateisystem je nach
gewähltem Mountpunkt temporär an das andere LPAR anzuhängen, falls der ursprüngliche Eigner
ausfällt.
Sie können katalogisierte Prozeduren systemspezifisch machen oder
&SYSNAME verwenden, um den Mountpunkt für das Konfigurationsdateisystem auszuwählen.
Wenn Sie tatsächlich denselben Mountpunkt für alle Konfigurationsdateisystemdateien verwenden
möchten, können Sie symbolische Verbindungen verwenden, um einen gemeinsamen Mountpunkt
auf jedem System an ein anderes Dateisystem umzuleiten:
- ln -s $SYSNAME/WebSphere WebSphere
- Konfigurationsdateisystem von LPAR1 an /LPAR1/WebSphere/V9R0F1 anhängen.
- Konfigurationsdateisystem von LPAR2 an /LPAR2/WebSphere/V9R0F1 anhängen.
Wenn Sie diesen Schritt korrekt ausführen, können Sie für jedes System in
Profile Management Tool oder im Befehl
zpmt den Mountpunkt "/WebSphere/V9R0F1"
für die Konfiguration
angeben und trotzdem die Vorteile systemspezifischer Anpassungsdateisystemdateien
genießen.
Bei Verwendung dieser Konfiguration ist es jedoch
nicht möglich, Konfigurationsdateisystemdateien auf einfache Art und Weise von einem
System auf ein anderes System zu verschieben. Alle Knoten erwarten, dass ihre Daten
in /WebSphere/V9R0F1 gespeichert sind, und Sie können in jedem System
nur ein Konfigurationsdateisystem an diesen Mountpunkt anhängen.
- Empfehlungen:
- Erstellen Sie auf einem einzelnen z/OS-System ein Dateisystem
mit Schreib-/Lesezugriff unter /wasv90config, verwenden Sie die Standardeinstellungen in Profile Management Tool, und hängen Sie jedes Konfigurationsdateisystem an
/wasv90config/Zellenname/Knotenname an.
- Auf einem Sysplex mit mehreren Systemen ohne gemeinsames Dateisystem sollten Sie
die oben aufgeführten Empfehlungen für ein einzelnes z/OS-System befolgen.
Auf diese Weise können Sie für jede Zelle
gemeinsame katalogisierte Prozeduren verwenden.
Definieren Sie auf jedem System für jede Zelle, die eventuell auf einem alternativen System
im Systemkomplex wiederhergestellt werden muss, separate Mountpunkte.
- Verwenden Sie in einem Systemkomplex mit mehreren Systemen mit gemeinsamem Dateisystem
dann ein gemeinsames Konfigurationsdateisystem, wenn die Leistung keine große Rolle spielt
oder wenn ein gemeinsames Dateisystem erforderlich ist, um spezielle Funktionen von
WebSphere Application Server for
z/OS zu unterstützen.
Verwenden Sie Konfigurationsdateisystemdateien, die nicht gemeinsam genutzt werden,
wenn die Leistung eine große Rolle spielt oder wenn Sie vermeiden möchten, dass
dass ein Single Point of Failure existiert.
Die Namen der Ausgangsverzeichnisse in
WebSphere Application Server festlegen
Das Ausgangsverzeichnis in
WebSphere Application Server ist immer relativ zum
Konfigurationsdateisystem, in dem es enthalten ist.
Wählen Sie deshalb in Profile Management Tool oder im Befehl zpmt in der einen Anzeige
der Mountpunkt für das Konfigurationsdateisystem aus, und geben in einer anderen Anzeige
lediglich den Namen für das Ausgangsverzeichnis ein.
Wenn Sie in den Anweisungen dazu aufgefordert werden, zum
WAS_HOME-Verzeichnis eines Servers zu wechseln, dann ist damit der gesamte Pfadname gemeint,
bestehend aus Konfigurationsdateisystem und Ausgangsverzeichnisname (z. B. /WebSphere/V9R0/AppServer).
Sie können für ein Ausgangsverzeichnis einen beliebigen
Namen festlegen, sofern er im Konfigurationsdateisystem eindeutig ist.
Falls Sie einen eigenständigen Anwendungsserver erstellen oder einen neu verwalteten Serverknoten,
der in eine
Network-Deployment-Zelle eingebunden werden soll,
achten Sie darauf, einen Namen festzulegen, der im Konfigurationsdateisystem der
Network-Deployment-Zelle nicht verwendet wird.
Falls ein Knoten pro System vorhanden ist,
ist es sinnvoll eine Form des Knotennamens oder Systemnamens zu verwenden.
Alternativ dazu, können Sie
DeploymentManager" für den Deployment Manager und
"AppServern für jeden Anwendungsserverknoten verwenden.
Beziehung zwischen dem Konfigurationsdateisystem und dem Produktdateisystem
Das Konfigurationsdateisystem enthält eine große Anzahl von symbolischen Verbindungen
zu Dateien im Produktdateisystem
(standardmäßig /usr/lpp/WebSphere/AppServer/V9R0).
Dies erlaubt es den Serverprozessen, dem Administrator und den Clients, auf eine einheitliche
Codebasis von WebSphere
Application Server for z/OS zuzugreifen.
Beachten Sie, dass diese
symbolischen Verbindungen definiert werden, wenn das WebSphere Application Server-Ausgangsverzeichnis erstellt wird, und dass es sehr schwierig ist,
sie zu ändern. Daher sollten Systeme, für die eine hohe Verfügbarkeit erforderlich ist,
zwecks Systemwartung für jeden verwendeten
Wartungs- oder Service-Level eine separate Kopie des Produktdateisystem von
WebSphere Application Server for z/OS
und der Produktdateien speichern (Test, Sicherung, Produktion usw.)
und symbolische Verbindungen verwenden, um jedes Konfigurationsdateisystem mit dem zugehörigen Produktdateisystem
zu verbinden.
Tipp: Wenn Sie bei der Konfiguration der
Network-Deployment-Umgebung in Profile Management Tool oder im Befehl
zpmt
den Standardwert für den Produktdateisystempfad verwenden,
zeigen alle Knoten direkt auf den Mountpunkt des Produktdateisystems.
Dadurch ist eine unterbrechungsfreie
Anwendung von Wartungspaketen beinahe unmöglich.
Wenn eine Zelle in dieser Art und Weise konfiguriert ist, dann
sind beim Anwenden von Service auf das Produktdateisystem
alle Knoten gleichzeitig betroffen, und
wenn mehrere Zellen in dieser Art und Weise konfiguriert sind,
sind beim Anwenden von Service auf das Produktdateisystem alle Zellen
gleichzeitig betroffen.
Es ist ratsam,
eine so genannte temporäre symbolische Verbindung zwischen
dem Konfigurationsdateisystem jedes Knotens und dem tatsächlichen Mountpunkt des Produktdateisystems anzugeben.
Diese Strategie wird im White Paper
WebSphere Application Server for z/OS V5 - Planning
for Test, Production and Maintenance erläutert. Weitere Informationen zu diesem Thema und seinem Bezug zur Wartung
finden Sie im White Paper
WebSphere z/OS V6 -- WSC Sample ND Configuration.
Im Artikel
WebSphere for z/OS: Updating an Existing Configuration
HFS to Use Intermediate Symbolic Links finden Sie
Anweisungen dazu, wie Sie ein Dienstprogramm erhalten und verwenden können,
mit dem ein vorhandenes Konfigurationsdateisystem für die Verwendung symbolischer Verbindungen
aktualisiert werden kann.
Wenn ein Knoten mit WebSphere Application
Server for z/OS gestartet wird, wird der Service-Level
der Konfiguration mit dem Service-Level des Produktdateisystems abgeglichen.
Ist der Service-Level des Konfigurationsdateisystems höher als der des Produktdateisystems
(was vermutlich darauf hinweist, dass ein älteres Produktdateisystem angehängt ist),
dann werden die Server des Knotens mit einer Fehlernachricht beendet.
Ist der Service-Level des Konfigurationsdateisystems niedriger als der des
Produktdateisystems (was darauf hinweist, dass
die Produktcodebasis seit dem letzten Start aktualisiert wurde),
stellt eine Task mit dem Namen "Post-installer" fest, welche Aktionen im Konfigurationsdateisystem
ausgeführt werden müssen, damit dieses auf den neuesten Stand gebracht wird.