Konfigurationsdateisysteme

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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=cins_planfs
Dateiname:cins_planfs.html