Bundesamt für Sicherheit in der Informationstechnik

M 4.221 Parallel-Sysplex unter z/OS

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Fachverantwortliche

Ein Parallel-Sysplex-Cluster ist ein Systemverbund aus mehreren z/OS-Systemen, die nach außen hin als ein System erscheinen. Dabei können die z/OS-Systeme auf einer oder auch auf mehreren LPARs (Logical Partitions) laufen. Zur Synchronisierung sind alle Systeme dieses Verbunds über eine Coupling Facility verbunden. Bei der Benutzung mehrerer LPARs muss zur Synchronisierung der System-Zeit (Clock) ein sogenanntes Timer Facility eingesetzt werden. Weitere Informationen hierzu finden sich in M 3.39 Einführung in die zSeries-Plattform . Parallel-Sysplex-Cluster kommen zum Einsatz, wenn hohe Anforderungen an die Verfügbarkeit und Skalierbarkeit bestehen.

Alle z/OS-Systeme eines Parallel-Sysplex-Clusters werden vom gleichen Festplattensatz geladen. Die einzelnen z/OS-Betriebssysteme werden über individuelle Systemdefinitionen unterschieden.

Beim Einsatz von Parallel-Sysplex-Clustern sollten folgende Empfehlungen beachtet werden:

Einsatz der Coupling Facility

Die Coupling Facility (CF) verbindet die LPARs untereinander. Sie stellt auch einen gemeinsam nutzbaren Speicher zur Verfügung, der in verschiedene Objekte, sogenannte Coupling Facility Structures, aufgeteilt ist. Der Zugriff auf die CF erfolgt über XES (Cross-System Extended Services). Es gibt drei verschiedene Speichertypen, die in der CF definiert werden können:

Cache Structures

Diese Struktur stellt hochperformanten Speicher für die gemeinsame Nutzung durch mehrere Anwender zur Verfügung. Werden Daten von der Festplatte gelesen, wird eine Kopie in den eigenen lokalen Speicherpuffer geschrieben. Darüber hinaus kann optional eine weitere Kopie in die Cache Structure der Coupling Facility gestellt werden.

List Structures

Diese Struktur erlaubt es mehreren Anwendern, Informationen miteinander zu teilen, die in Listen (Message passing) oder Warteschlangen (Queues of work) verfügbar sind.

Lock Structures

Diese Struktur kann verwendet werden, um die Benutzung von Ressourcen im Shared- oder Exclusive-Modus über alle LPARs zu steuern.

Einsatz

Wird der Betrieb eines Parallel-Sysplex-Clusters erwogen, z. B. aus Verfügbarkeitsgründen, sollte die Coupling Facility möglichst mit Data Sharing eingesetzt werden. Dies gilt zumindest für JES2/3 (Job Entry Subsystem), RACF (Resource Access Control Facility), VTAM (Virtual Telecommunication Access Method), System Logger, CICS , IMS und DB2. Es sollte geprüft werden, ob eine redundante Auslegung der Coupling Facility erforderlich ist, um den Anforderungen an die Verfügbarkeit des Gesamtsystems Rechnung zu tragen.

Coupling Facilities werden über die HMC (Host Management Console) definiert und initialisiert. Empfehlungen zum Einsatz dieser Konsole finden sich in M 4.207 Einsatz und Sicherung systemnaher z/OS-Terminals .

Couple Datasets

Die Couple Datasets werden von XCF (Cross-System Coupling Facility) benutzt, um Informationen über die LPARs, Gruppen oder Member zu kontrollieren. Alle LPARs des Parallel-Sysplex-Verbundes müssen auf diese Datasets zugreifen können. Der Einsatz von Alternate CoupleDatasets ist zu empfehlen. Unter z/OS müssen die Couple Datasets über RACF geschützt werden. Es sollten nur die Mitarbeiter verändernden Zugriff darauf erhalten, die im Rahmen ihrer Tätigkeit die Dateien bearbeiten, sowie deren Vertreter (siehe M 4.211 Einsatz des z/OS-Sicherheitssystems RACF ).

Zum Formatieren der Couple Datasets steht das Utility IXCL1DSU zur Verfügung. Dieses Programm sollte über RACF geschützt werden (Class PROGRAM). Das administrative Utility XCMIAPU erlaubt die Definition der CFRM-Policy (Coupling Facility Resource Management). Es sollte über ein entsprechendes Facility-Profil im RACF geschützt werden, so dass nur autorisiertes Personal Zugriff darauf hat. Weitere Empfehlungen zum Schutz kritischer Programme finden sich in M 4.215 Absicherung sicherheitskritischer z/OS-Dienstprogramme .

Sysplex-Kommandos

Zur Administration und Kontrolle stellt das z/OS-Betriebssystem das System-Kommando SETXCF zur Verfügung. Es unterstützt unter anderem die folgenden Aktivitäten:

  • Definieren der Couple Datasets
  • Umschalten zwischen Primary- und Backup-Couple Dataset
  • Aktivieren einer neuen CFRM-Policy
  • Start der PATHIN- oder PATHOUT-Verbindung
  • Ändern der Struktur-Größe (Structure Size)
  • Rebuild der Struktur nach Struktur-Fehlern

Zum Schutz dieses Kommandos (und aller anderen den Parallel-Sysplex-Cluster unterstützenden Kommandos) müssen entsprechende RACF-Profile definiert werden (siehe M 4.210 Sicherer Betrieb des z/OS-Betriebssystems ).

XCF Kontrolle

RMF (Resource Measurement Facility) erzeugt einen sogenannten XCF Activity Report. Es ist zu überlegen, diesen Report zur Überwachung des Nachrichtenverkehrs zwischen den z/OS-Betriebssystemen einzusetzen, um Kommunikationsengpässe und Deadlock-Situationen rechtzeitig erkennen und präventive Maßnahmen ergreifen zu können.

Einheitliche RACF-Datenbank

Für alle LPARs des gesamten Parallel-Sysplex-Clusters sollte eine RACF-Datenbank mit einheitlichen RACF-Definitionen verwendet werden.

Standards

Um die Übersichtlichkeit und Wartbarkeit zu verbessern, sollten in folgenden Bereichen Standards eingeführt werden:

  • Die Parameter-Member der PARMLIBs sollten standardisiert werden. Alle Namen müssen im Parallel-Sysplex-Verbund eindeutig sein. Hierzu gehören: Dataset-Namen, Subsystem-Namen, Prozedur-Namen, VTAM Application IDs (siehe M 2.285 Festlegung von Standards für z/OS-Systemdefinitionen ).
  • Sämtliche Systemeinstellungen der lokalen Definitionen in PARMLIB und PROCLIB sollten einheitlich sein. Es ist empfehlenswert, dass der strukturelle Aufbau der einzelnen Definitions-Member identisch ist.
  • Die SMS-Struktur (System Managed Storage) muss im gesamten Parallel-Sysplex-Verbund einheitlich sein.
  • Auf allen LPARs sollte eine möglichst einheitliche System-Software eingesetzt werden (eventuell ist hierdurch eine Anpassung der Software-Lizenzen notwendig).

Dimensionierung

Es muss auf die richtige Dimensionierung der Caches der Festplatten-Steuereinheiten, der Work-Platten, der Strukturen in der Coupling Facility und der SPOOL-Platten geachtet werden. Die Größe der Bereiche ergibt sich in erster Linie aus der Art und den Anforderungen der Anwendungen, die auf dem Parallel-Sysplex-Verbund laufen. In vielen Fällen enthalten auch die Dokumentationen der Software-Hersteller Hinweise hierzu.

Serialisierung

Es muss ein GRS-Verbund (Global Resource Serialization) eingerichtet werden, um die System-Aktionen serialisieren zu können. Der GRS-Modus muss im Member IEASYSnn der PARMLIB definiert sein (RING- oder STAR-Modus). Es sollte, wenn möglich, der modernere STAR-Modus gewählt werden, da diese Topologie durch die auf den Couple Datasets gespeicherten Resource Name Lists (RNLs) meist eine schnellere Verarbeitung bietet. Auch in Bezug auf die Verfügbarkeit ist der STAR-Modus in der Regel vorteilhafter.

Achtung: Der STAR-Modus ist nur mit Coupling Facility möglich.

Hochverfügbarkeit durch Redundanz

Bei hohen oder sehr hohen Anforderungen an die Verfügbarkeit sollte geprüft werden, ob die folgenden Redundanzmechanismen zweckmäßig sind:

  • RACF mit Primary- und Backup-Datenbank
  • Zweite Coupling Facility
  • Alternate Couple Datasets
  • Zweiter Timer (gekoppelt über Hochverfügbarkeitseinrichtung FC 4048, mit eigenem Stromkreis)
  • Backup-Systemumgebung, damit im Fehlerfall ein System-Reboot ohne Zeitverzögerung erfolgen kann
  • CTC-GRS-Ring (Kanalverbindung ESCON / General Resource Serialization)
  • Backup-MCS-Masterkonsole (Multiple Console Support)
  • Datensicherung von wichtigen Kontrolldateien, wenn möglich, mit der Option Concurrent Copy realisieren (Utility ADRDSSU)

Weitere Hinweise finden sich in M 6.93 Notfallvorsorge für z/OS-Systeme .

Festplattenzugriffe

Bei den Festplattenzugriffen sind folgende Empfehlungen zu beachten:

  • Im Parallel-Sysplex-Verbund sollten keine Festplatten außerhalb des Verbundes zur Verfügung stehen. Festplatten, die nicht zum Verbund gehören, sollten nur für Recovery-Maßnahmen Online gesetzt werden können.
  • Der Zugriff auf Festplatten des Parallel-Sysplex-Verbundes von anderen, nicht zum Verbund gehörenden Systemen sollte unter Produktionsbedingungen nicht möglich sein.
  • Es ist zu überlegen, ob die Option Enhanced Catalog Sharing eingesetzt werden soll, wenn hohe Performance-Anforderungen vorliegen.
  • Test-/Entwicklungs-Systeme und Produktions-Systeme sollten möglichst nicht im selben Parallel-Sysplex-Cluster betrieben werden.
  • Das Betriebssystem sollte für alle z/OS-Systeme im Parallel-Sysplex-Cluster von einem Systemplatten-Satz geladen werden.

Symbolische Variablen

Es sollten symbolische Variablen an möglichst vielen Stellen der PARMLIB-Definitionengenutzt werden. Dies hilft, Fehler bei der Systemadministration zu vermeiden und erleichtert das System-Cloning.

System Logger

Der System Logger sollte mit Staging Dataset eingesetzt werden. (Im Fehlerfall wird auf diese Datasets von anderen Systemen im Verbund aus zugegriffen.)

Reduzierung der Konsol-Nachrichten

Um die Konsol-Meldungen zu reduzieren und überschaubar zu halten, wird empfohlen, die Message-Filterung zu aktivieren (siehe M 4.210 Sicherer Betrieb des z/OS-Betriebssystems ). Dies ist besonders wichtig, da alle Nachrichten von allen z/OS-Betriebssystemen eines Parallel-Sysplex-Clusters auf einer MVS-Konsole angezeigt werden.

Prüffragen:

  • Bei Einsatz eines Parallel-Sysplex-Clusters unter z/OS : Wird geprüft, ob eine redundante Auslegung der Coupling Facility erforderlich ist, um den Anforderungen an die Verfügbarkeit des Gesamtsystems Rechnung zu tragen?

  • Wird der Zugriff auf die Couple Datasets unter z/OS über RACF geschützt?

  • Wird das administrative z/OS -Utility XCMIAPU über ein entsprechendes Facility-Profil im RACF geschützt, so dass nur autorisiertes Personal Zugriff hat?

  • Wird für alle LPAR s des gesamten Parallel-Sysplex-Clusters unter z/OS eine RACF -Datenbank mit einheitlichen RACF -Definitionen verwendet?

  • Ist die System Managed Storage-Struktur im gesamten Parallel-Sysplex-Verbund unter z/OS einheitlich?

  • Bei Einsatz eines Parallel-Sysplex-Clusters unter z/OS : Ist ein GRS -Verbund zur Serialisierung von System-Aktionen eingerichtet?

  • Werden im Parallel-Sysplex-Cluster unter z/OS ausschließlich Festplatten innerhalb des Verbundes zur Verfügung gestellt?

  • Wird der Zugriff auf Festplatten des Parallel-Sysplex-Clusters unter z/OS von Systemen außerhalb des Verbundes verhindert?

Stand: 13. EL Stand 2013