Die der Dateiverarbeitung dienenden Schnittstellen des DVS werden durch die Schnittstellen des hierarchischen Speicherverwaltungssystems HSMS ergänzt. HSMS verwaltet die Ablage von Dateien auf den drei Speicherebenen von BS2000 und die Bewegung von Dateien zwischen diesen:
Verarbeitungsebene (S0)
Hintergrundebene 1 (S1) mit Online-Zugriff
Hintergrundebene 2 (S2) ohne Online-Zugriff
Auf der Basis dieser Speicherebenen realisiert HSMS Migration, Backup und Archivierung von Dateien und Job-Variablen.
Die von HSMS benötigten Metadaten „Archivdefinition“ und „Directory“ sind nicht an einen Pubset gebunden (ausgenommen die im nächsten Abschnitt behandelten System Managed Pubsets). Die Archiv-Definitionen werden auf dem Default Pubset der Kennung des HSMS-Verwalters abgelegt, also in der Regel auf dem Home-Pubset des Rechners. Der Ablageort eines Directory ist frei wählbar.
Auch die HSMS-Schnittstelle steht in Shared-SF-Pubset-Umgebung grundsätzlich in vollem Umfang zur Verfügung (SM-Pubsets werden im nächsten Abschnitt behandelt). Die Aufträge für Datenobjekte auf einem Shared-SF-Pubset werden am Master-Rechner ausgeführt, unabhängig, von welchem Rechner des Verbunds der Auftrag erteilt wird. Aufträge, die Dateien von mehreren Shared-Pubsets umfassen, werden nur akzeptiert, wenn alle Pubsets denselben Master-Rechner haben. Nach Ausfall eines Master-Rechners ist eine Verlagerung unterbrochener Sicherungsaufträge nicht möglich, wiederanlauffähige Aufträge können jedoch, wenn der ausgefallene Rechner wieder verfügbar ist, dort fortgesetzt werden, auch wenn dieser Rechner nach einem Neustart des Systems lediglich im Slave-Modus am MSCF-Verbund teilnimmt.
Zur Verkleinerung des Zeitfensters von Sicherungsläufen dient die Funktion „Concurrent Copy” (CCOPY). Sie ermöglicht die Sicherung eines konsistenten Stands einer Dateimenge, wobei die Dateien nach einer Initialisierungsphase, nach der die Sicherung logisch beendet ist, in beliebiger Weise parallel zur Sicherung bearbeitet werden können. Dabei kann für die Sicherung ein konsistenter Stand auf folgende Weise zur Verfügung gestellt werden:
Vor der Änderung eines Blocks einer Datei der Sicherungsmenge wird eine Kopie dieses Blocks in einer Arbeitsdatei hinterlegt (Schreiben von „Before Images“)
Wenn zusätzliche, frei konfigurierbare Spiegel-Volumes zur Verfügung stehen, dann können bei der Initialisierung der Sicherung diese zusätzlichen Spiegel abgetrennt werden. Die Sicherung kann dann von diesen Spiegeln erfolgen.
CCOPY wird auch im Shared-Pubset-Verbund unterstützt. Dabei ist Folgendes zu beachten:
CCOPY mit „Before Images“:
Für Dateien auf einem Shared-Pubset wird der Kopiervorgang zur Erstellung eines „Before Image“ stets auf dem Master-Rechner durchgeführt, ein entsprechender Kopierauftrag wird vom Slave-Rechner an den Master-Rechner übersandt. Der Verbindungsverlust eines Slave-Rechners zum Master-Rechner macht jedoch das Versenden eines Kopierauftrags an den Master-Rechner unmöglich und führt deshalb zum Abbruch der Sicherung. Nach einem Ausfall des Master-Rechners ist das erneute Starten des Sicherungslaufs nicht möglich, da Sicherungsaufträge mit CCOPY nicht wiederanlauffähig sind. Der Sicherungslauf muss vollständig neu aufgesetzt werden.CCOPY mit Spiegelplatten:
Der Shared-Pubset-Verbund wird unterstützt.
Nach Abschluss der Sicherung wird die Spiegelung wieder aufgenommen. Sicherungsaufträge mit Spiegelplatten sind wiederanlauffähig.
Weitergehende Informationen über HSMS enthält das Handbuch „HSMS“ [8].
Die Funktionen für Spiegelplatten sind im Handbuch „SHC-OSD“ [18] beschrieben.