Mobile-Menu

Auszug aus dem IBM Storage System Kompendium

Der System-verwaltete Speicher im Mainframe-Umfeld, Teil 2

Seite: 3/4

Anbieter zum Thema

Komponenten und Funktionen

Die Abbildung „z/OS components for centralized storage and data management“ in der Galerie zeigt die System-Komponenten im z/OS, die für die Allocation, also die Platzierung in der Storage-Hierarchie, verantwortlich sind. Sie zeigt auch die Komponenten, die für das Space Management und die Availability angezogen werden.

Neben dem DFSMSdfp kommt auch der SRM von z/OS für die „data set allocation“ zum Einsatz, wenn eine Datei neu angelegt wird. Für das Space Management und das Availability Management

sind alle vier Komponenten miteinander verknüpft. Jede Komponente hat einen bestimmten Auftrag innerhalb von SMS zu erfüllen:

  • 1. DFSMSdfp – stellt das Interface zu den Policies her und instruiert die anderen Komponenten
  • 2. DFSMSdss – ist eine Art Data Mover und bewegt fast alle Dateien
  • 3. DFSMShsm – ist zuständig für das Space- und Availability Management. DFSMShsm bestimmt, welche Datei für Backup-Zwecke kopiert wird bzw. schafft freien Platz, indem nicht aktive Dateien ausgelagert und migriert werden.
  • 4. DFSMSrmm – ist für die Aufzeichnung der Kassetteninhalte bzw. für die Dateien auf Tape verantwortlich.

DFSMS arbeitet mit zwei Repositories, dem Active Control Data Set (ACDS) und dem Communication Data Set (COMMDS). DFSMShsm und DFSMSrmm haben jeweils eigene Repositories, die aber über DFSMSdfp mit den DFSMS-Dateien ergänzt und abgeglichen werden.

Space Management

Über die SMS-Konstrukte und hier speziell über die Management Class werden Service Level Objectives bzgl. dem verfügbaren Platz auf Disk Storage Subsystemen bzw. den Volumes in einem solchen Subsystem spezifiziert. Das Ziel ist, dass Anwendungen nicht abbrechen, weil ein Problem mit nicht genügend freiem Platz aufgetreten ist.

DFSMShsm ist die DFSMS-Komponente, die die Policies für das Space Management überwacht und notwendige Aktionen ausführt, wenn die Policies nicht mehr eingehalten sind. Dabei werden neben der Management Class auch Angaben der Storage Groups herangezogen, um den Platz auf allen verwalteten Volumes in den Disk-Storage-Subsystemen auf Datei-Level zu verwalten. Das Kriterium sind sogenannte Thresholds auf Volume Level und auf Storage Group Level, die eingehalten werden müssen, um immer genügend freien Platz für neue Dateien bereitzuhalten.

Dieser Migrationsprozess erfolgt periodisch und es werden nicht aktive Dateien als Kandidaten für eine Verlagerung auf eine andere Klasse der Speicherhierarchie von DFSMShsm ausgewiesen.

Auch wenn eine Datei von einem Volume in eine von DFSMShsm verwaltete Disk-/Tape-Speicherhierarchie verlagert wurde, bleibt die Datei nach wie vor katalogisiert. Wenn eine solche Datei von der Anwendung referenziert wird, führt DFSMShsm automatisch einen „Recall“ durch und bringt die Datei zurück auf ein aktives Application Volume. Dieser Prozess ist für die betroffene Anwendung oder den Benutzer völlig transparent und unbemerkt.

DFSMShsm löscht auch automatisch Dateien, deren Lebensdauer nach ihrer zugewiesenen Management Class abgelaufen ist (deleting expired data sets). Es werden aber auch temporäre Dateien gelöscht oder es wird Platz freigegeben, der innerhalb einer Datei nicht mit Daten genutzt ist, wenn das durch die zugehörige Management Class als Attribut verlangt wird.

Weiter mit: Availability Management

(ID:2044736)