Auszug aus dem IBM Storage System Kompendium Der System-verwaltete Speicher im Mainframe-Umfeld, Teil 1

Autor / Redakteur: Werner Bauer / Nico Litzel

Wie der Name impliziert, wird die externe Speicherumgebung durch das System, genauer gesagt durch den angeschlossenen Server und dessen Betriebssystem, verwaltet. Verwaltet heißt in diesem Zusammenhang, dass das Betriebssystem automatisch alle Aktivitäten im Zusammenhang mit externem Speicher nach einem vordefinierten Regelwerk – Policy-basierend – verwaltet.

Firma zum Thema

Neben dem Abgleich der logischen Anforderungen an eine Datei mit der physisch vorhandenen Konfiguration wird von einer automatischen Speichermanagement-Lösung erwartet, dass die Dateien sinnvoll in der vorhandenen Speicherhierarchie abgelegt und nach Anforderung bewegt werden.
Neben dem Abgleich der logischen Anforderungen an eine Datei mit der physisch vorhandenen Konfiguration wird von einer automatischen Speichermanagement-Lösung erwartet, dass die Dateien sinnvoll in der vorhandenen Speicherhierarchie abgelegt und nach Anforderung bewegt werden.
( Archiv: Vogel Business Media )

Andere oder ähnliche Begriffe für den systemverwalteten Speicher – System Managed Storage – sind Information Lifecycle Management (ILM) oder Scale-out File Services (SoFS). Solche Begriffe finden sich in IT-Landschaften, die vornehmlich mit Unix- und/oder Intel-basierenden Servern ausgestattet sind. System Managed Storage oder kurz SMS wurde durch die Ansätze im Mainframe- und Host-Umfeld in den 80er-Jahren des vergangenen Jahrhunderts massiv geprägt.

Dieser Ansatz wurde in den Anfängen bereits 1974 durch das Mass Storage System IBM 3850 eingeführt, wo bereits eine HSM-Funktionalität zur Verfügung gestellt wurde, um Daten, die nicht oft benötigt wurden, auf einem billigen Massenspeicher systemgesteuert abzuspeichern (siehe auch unter IBM 3850).

SMS hatte zum Ziel, das rasante Speicherwachstum der damaligen Zeit rasch zu adaptieren, ohne die Anzahl der Speicheradministratoren analog mitwachsen zu lassen. SMS verhält sich – fast – völlig elastisch zu dem wachsenden externen Speichervolumen, skaliert ausgezeichnet und verwaltet ein auf 400-Gigabyte-Disks basierendes Speicherumfeld aus dem Jahr 1990 genauso gut wie heute eine 4.000.000 Gigabyte große Disk-Konfiguration.

Speicherhierarchie

Neben dem Abgleich der logischen Anforderungen an eine Datei mit der physisch vorhandenen Konfiguration wird von einer automatischen Speichermanagement-Lösung erwartet, dass die Dateien sinnvoll in der vorhandenen Speicherhierarchie abgelegt und nach Anforderung bewegt werden. Heutige Plattensysteme können mit SSDs (Solid State Disks), Fibre-Channel-Platten und SATA-Platten bestückt werden und dadurch systemintern eine Speicherhierarchie abbilden. SSDs sind zwar noch sehr teuer, bieten dafür aber extrem schnellen Zugriff und extrem schnelle Antwortzeiten.

Die Speicherhierarchie wird bei den Magnetplatten durch zwei gegenläufige Trends bestimmt: Je schneller der Speicherzugriff und je besser und kürzer die Servicezeit ist, desto teurer ist das gespeicherte Gigabyte. Anders ausgedrückt: Das gespeicherte Gigabyte wird preiswerter, wenn die Anforderungen an Zugriffszeit und Schnelligkeit geringer werden.

Ein schnelles Fibre-Channel-Plattenlaufwerk dreht mit 15.000 Umdrehung pro Minute respektive 250 Umdrehungen pro Sekunde, das heißt, eine Umdrehung dauert vier Millisekunden. Die übliche Kapazität einer Fibre-Channel-Disk liegt heute zwischen 300 und 650 Gigabyte mit einem Formfaktor von 3,5 Zoll Durchmesser. Die Anzahl der möglichen Zugriffe ist durch die hohe Umdrehungszahl wesentlich schneller im Vergleich zu einer preiswerten, hochkapazitiven SATA-Platte mit 7.200 Umdrehungen pro Minute bzw. 120 Umdrehungen pro Sekunde mit 8,3 Millisekunden pro Umdrehung. Das dauert mehr als doppelt so lange im Vergleich zu einer Fibre-Channel-Platte.

Die Kapazitäten bei SATA-Platten liegen heute bei ein und zwei Terabyte. Eine übliche Größe, um die Leistungsfähigkeit einer Platte einzuordnen, ist die Anzahl von Ein-/Ausgabe-Zugriffen pro Sekunde und pro Gigabyte. Das macht deutlich, dass SATA wesentlich schwächer als eine Fibre-Channel-Platte ist und daher für hochaktive Dateien ungeeignet ist. Die Technologie für 15.000 U/M ist auch anspruchsvoller – und damit teurer – als die notwendige Technologie, um mit nur 7.200 Umdrehungen pro Minute zu rotieren.

Weiter mit: Virtuelle Tape-Konfigurationen im Mainframe-Umfeld

Virtuelle Tape-Konfigurationen im Mainframe-Umfeld

Eine spezielle Rolle im Mainframe-Umfeld kommt virtuellen Tape-Konfigurationen zu. Um den Vorteil des direkten Zugriffs der Platte für Backup und ausgelagerte Dateien zugänglich zu machen, aber andererseits ökonomisch mit dem genutzten Speicherplatz umzugehen, wird eine Technologie genutzt, die vermeidet, dass gleiche Datenstrukturen mehrfach gespeichert werden („Deduplication“). Dabei wird auf reale Tape-Laufwerke gänzlich verzichtet und die Backup-Dateien und die ausgelagerten Daten („migrated data sets“) werden auf Disks abgespeichert. Ein solches System simuliert Tape-Laufwerke gegenüber den angeschlossenen z/OS-Servern.

Automatische Tape Libraries und Virtuelle Tape Server nutzen aber – sinnvoll – weiterhin reale Bandlaufwerke und Kassetten, auf denen letztlich die Dateien abgelegt werden, nachdem die geschriebenen Tape-Daten durch einen vorgeschalteten Plattenpuffer gegangen sind. Über einen solchen Plattenpuffer können wieder virtuelle Tape-Laufwerke emuliert werden, die viele Tape-Laufwerke pro virtuellem Tape Server simulieren. Das eigentliche Backend besteht nur aus wenigen realen Kassettenlaufwerken, über die hochkapazitive Kassetten beschrieben werden. Diese realen Kassetten-Laufwerke sind in einem virtuellen Tape Server für das z/OS-Betriebssystem nicht sichtbar.

Storage Management Software

Das Data Facility Storage Management Subsystem (DFSMS/MVS) setzt heute den Standard der Storage Management Software, ohne die das Speicherwachstum in den vergangenen Jahren im Mainframe-Umfeld nicht administrierbar gewesen wäre. Die Anfänge von DFSMS/MVS gehen zurück bis in die frühen 80er-Jahre des vergangenen Jahrhunderts. Damals haben Kunden und entsprechende Benutzerorganisationen einschließlich der IBM die Notwendigkeit für ein vollautomatisches Speichermanagement erkannt:

  • Rapides Speicherwachstum
  • Die TCO für Speicher eskalierten bereits in den Jahren ab Anfang 1980
  • „Storage keeps getting cheaper, but also harder to manage“, Datamation, 15.12.1985
  • GUIDE/SHARE fordert IBM in den Jahren 1983 bis 1985 auf, ein „policy based storage management“ anzubieten und definiert „requirements for futures of storage management“, GUIDE 1983
  • „Without improvements in methods, or the emergence of improved automated managers, the storage management forces will have to grow exponentially as the data grows“, GUIDE Paper, 15.11.1985
  • Internet, e-business, b-2-b interactions, life sciences, WEB 2.0, etc. tragen weiterhin zu einer verstärkten Explosion der Nachfrage nach Speicherkapazität bei, die verwaltet werden muss.

Automatisches Storage und Daten-Management wurde mit DFSMS/MVS realisiert und wird in den folgenden Abschnitten beschrieben.

Weiter mit: Data Facility Storage Management Subsystem

Data Facility Storage Management Subsystem

IBM hat 1989 mit MVS/DPF 3.0 die zweite Stufe einer Strategie realisiert, die unter dem internen Begriff „Jupiter Strategy“ in den frühen 80er-Jahren entstanden ist. Diese zweite Stufe ist das, was wir heute im Host-Umfeld als SMS verstehen.

Die Jupiter-Strategie war damals in drei Stufen geplant:

1. Jupiter Stage I ist das, was im DFSMS/MVS bzw. z/OS als Interactive Storage Management Facility (ISMF) verstanden wird. ISMF ist ein Panel-basierendes „Frontend“ zu dem externen Speicher und dem dazugehörigen Repository, in dem der externe Speicher in einer speziellen, sehr effektiven und effizienten Datenbank verzeichnet ist. ISMF war der erste Schritt und wurde 1987 angekündigt und im Markt eingeführt.

2. Jupiter Stage II wurde 1989 als MVS/DFP 3.0 angekündigt und allgemein verfügbar. Neben dem Data Facility Product (DFP) waren auch die Komponenten Data Set Services (DSS), der Hierarchical Storage Manager (HSM) und der Removable Media Manager (RMM) integraler Bestandteil dieser Jupiter Stufe II. Das ist der Stand von SMS, wie er heute im Mainframe-Umfeld bekannt ist. Er trägt der Realisierung des Gedankens Rechnung, den Speicher durch das Betriebssystem nach einem vordefinierten Regelwerk automatisch zu verwalten. Über die Jahre hinweg wurde diese Stufe verfeinert und ergänzt und ist heute unter z/OS integraler Bestandteil der Betriebssystemsoftware.

3. Jupiter Stage III war als letzte Stufe geplant. In dieser Stufe sollte die völlige Trennung von logischen Daten und physikalischer Speicherung umgesetzt werden. Dabei sollte der externe Speicher auf eine Block-Level-Architektur standardisiert und die logischen Daten automatisch so platziert werden, wie es über Regeln und Service-Levels vorgegeben ist. Sollte eine Regel – oder der geforderter Service-Level – nicht mehr eingehalten werden können, sorgt das System selbst dafür, dass die betroffenen Blöcke automatisch und für die Anwendung unbemerkt in der Speicher-Hierachie so umverlagert werden, dass der geforderte Service-Level wieder eingehalten werden kann.

Anfang der 90er-Jahre entschied IBM, diese dritte Stufe im Rahmen der Jupiter-Strategie nicht mehr zu verwirklichen. Man ging davon aus, dass eine entsprechende Investition eher für Unix-basierende Server gemacht werden sollte.

Weiter mit: Dateien im z/OS

Dateien im z/OS

Bevor wir SMS und seine Komponenten genauer betrachten, wollen wir das Prinzip der Datei im z/OS beschreiben bzw. wie eine Datei angelegt und wiedergefunden wird. Jede Datei – vergleichbar mit einer „File“ in Unix oder Windows – bekommt im z/OS einen eindeutigen Namen bzw. genauer einen Dateinamen, ein „Data Set Name“ (DSN) zugeordnet. Ein DSN kann bis zu 44 Character lang sein und besteht aus einzelnen „Qualifiern“. Diese Qualifier sind zwischen einem und acht Caracter lang und bestehen aus alpha-numerischen Zeichen. In der Regel gibt es keine Vorschriften, wie solch ein Name ausgeprägt sein muss. Ein Beispiel: „SAP.PROD.KDNR1984.INDEX“ hat den ersten Qualifier mit SAP, der auch als High Level Qualifier (HLQ) bezeichnet wird, einen zweiten Qualifier PROD, den dritten Qualifier KDNR1984 und den sogenannten Last Level Qualifier (LLQ) mit INDEX. Die Qualifier sind jeweils durch einen Punkt getrennt.

Solch ein Name kann vom System genauso zerlegt und geprüft werden. Beispielsweise kann eine Regel definiert werden, die lautet . Unter &variable_llq ist beispielsweise INDEX, VER*, GRUPPE1 als mögliche LLQ-Liste definiert, wobei dieser LLQ auch mit den ersten drei Zeichen VER in die Auswahl fallen würde. Dabei wäre gleichgültig, wie die anderen Qualifier ausgeprägt sind. Also eine Datei mit DSN=TEST.D30M09.VERZ1 würde die Auswahl als gültig akzeptieren, da in der LLQ-Liste auch VER* steht.

Mit entsprechenden UND-Verknüpfungen von weiteren Regeln kann die Auswahl selektiver ausfallen wie etwa mit SAP*,PROD als Liste in der Variablen &variable_hlq. Dann fallen alle DSN mit SAP in den ersten drei Stellen des HLQ und mit den LLQ, wie in der Variablen &variable_llq definiert, in die Auswahl.

Eine Datei muss in einem SMS Environment immer katalogisiert sein. Ein Katalog ist ein Verzeichnis, in dem jede einzelne Datei mit Namen verzeichnet ist und wo diese Datei zu finden ist. Das wird über ein Volume Label oder die sogenannte Volume Serial Number, VOLSER, bewerkstelligt. Die VOLSER ist ebenfalls eindeutig in einem SMS-System. Mit Hunderttausenden oder Millionen von Dateien in einem großen System wird man nicht nur einen einzigen Katalog nutzen, sondern über den HLQ auf bestimmte Kataloge zugehen.

Weiter mit: Master Catalog

Master Catalog

In unserem Beispiel sind alle Dateien, die SAP als HLQ ausweisen, in dem Katalog U.SAP katalogisiert. Da auch die Kataloge über einen DSN gefunden werden müssen, gibt es eine übergeordnete Instanz, die „Master Catalog“ genannt wird. Es gibt nur einen einzigen aktiven Master Catalog in einem SMS-System. Dessen Inhalt wird Speicherresident im z/OS vorgehalten, da er für jedes „Data Set Locate“ angezogen werden muss, um den zugehörigen [user] Catalog anzuziehen.

Das geschieht über den HLQ und wird als ALIAS-Beziehung bezeichnet. Im Master Catalog wird SAP als HLQ eingetragen und der Verweis auf den user catalog U.SAP. Immer wenn ein DSN auftaucht, der SAP als HLQ ausweist, wird in dem Katalog U.SAP diese Datei definiert oder gesucht. Da der Katalog nur auf ein Volume verweist, auf dem die Datei abgelegt wird oder abgelegt ist, hat jedes Volume ebenfalls eine feste Struktur, damit die Datei letztlich auf dem Volume Level gefunden oder entsprechend eingetragen werden kann. Das „Volume Label“ steht immer auf der gleichen Stelle eines jeden Volumes, Cylinder 1, Spur 1, Record 1. Das Label hat u. a. auch einen Zeiger zum Inhaltsverzeichnis des Volumes, die sogenannte Volume Table Of Content oder VTOC.

Die VTOC ist funktionell grob mit einem File System in Unix oder Windows vergleichbar. In der VTOC stehen alle DSNs, die ein Zuhause auf diesem Volume haben, und die Anfangs- und Endadresse dieser Datei auf dem Volume. Eine Datei oder DSN ist also ein eindeutiger Name innerhalb einer SMS-Konfiguration und die zugehörige Datei muss immer katalogisiert sein. Die Anforderung, eine neue Datei anzulegen, geht durch das SMS – genauer gesagt durch das DFSMS, Allocation und Catalog Management – und sucht einen passenden Platz in der Speicherhierarchie, abhängig von dem geforderten Service-Level, der für diese neue Datei vorgegeben wird.

Eine Anforderung für eine bereits bestehende Datei geht nur durch die Allocation und das Catalog Management, um die bestehende Datei zu lokalisieren und der Anwendung zugänglich zu machen.

Im zweiten Teil: Policy-based Storage Management im Überblick, SMS für Tape und Space- und Verfügbarkeitsmanagement

Dieser Artikel ist ein Auszug aus dem IBM-System-Storage-Kompendium. Hier finden Sie das vollständige Kompendium in Form eines Whitepapers.

(ID:2044714)