Sicherungsbetrieb mit Snapsets
Sind die Vorbereitungen abgeschlossen, kann der Snapset-Betrieb (im Beispiel für den Pubset A) aufgenommen werden, d.h. die Systembetreuung bzw. die HSMS-Administration kann zu den geplanten Zeitpunkten Pubset-Kopien (=Snapsets) erstellen.
Beispiel
Pubset A soll an jedem Arbeitstag zweimal (mittags und abends) gesichert werden.
Snapset erstellen
Jeweils zu dem gewünschten Sicherungszeitpunkt erstellt die Systembetreuung bzw. die HSMS-Administration mit dem Kommando CREATE-SNAPSET einen Snapset:
/CREATE-SNAPSET PUBSET=A
Das Kommando kann im Shared-Pubset-Betrieb an allen beteiligten Systemen eingegeben werden.
Zu einem Zeitpunkt kann für den gleichen Pubset nur ein Kommando CREATE-SNAPSET gegeben werden. Parallele Aufrufe werden serialisiert.
Als Voreinstellung des Kommandos wird bei erreichtem Snapset-Limit implizit der älteste Snapset gelöscht. Optional kann im Operanden DELETE-EARLIEST auch vereinbart
werden, dass in jedem Fall der älteste Snapset implizit gelöscht wird oder dass in keinem Fall implizit gelöscht wird.
Der neu erzeugte Snapset wird automatisch in Betrieb genommen und steht damit allen Benutzern für Restore-Zwecke zur Verfügung.
Snapset-Identifikation
Jeder neu erzeugte Snapset erhält eine eindeutige Snapset-Identifikation. Für die maximal 52 möglichen Snapsets werden fortlaufend in alphabetischer Reihenfolge zuerst die Kleinbuchstaben „a“ bis „z“, dann die Großbuchstaben „A“ bis „Z“ vergeben. Nach Erreichen von „Z“ beginnt die Vergabe wieder mit „a“ (die zeitliche Reihenfolge der Snapset-Erzeugung entspricht deshalb nicht immer der alphabetischen Reihenfolge der Snapset-Ids). An der Kommandoschnittstelle muss die Groß-/Kleinschreibung beachtet werden.
Jede Snap-Unit erhält eine VSN, die aus der VSN der Originalplatte und aus der Snapset-Identifikation gebildet wird.
Beispiele zur Verdeutlichung der Abbildungsregel
VSN in PUB-Notation und Snapset-Id als Kleinbuchstabe, z.B. „a“: PUBX12 --> PaaX12
VSN in PUB-Notation und Snapset-Id als Großbuchstabe z.B. „A“: PUBX12 --> aaBX12
VSN in Punkt-Notation und Snapset-Id als Kleinbuchstabe, z.B. „a“:
AB.123 --> ABa123; ABC.12 --> ABCa12; ABCD.1 --> ABCDa1
VSN in Punkt-Notation und Snapset-Id als Großbuchstabe, z.B. „A“:
AB.123 --> AB123a; ABC.12 --> aABC12; ABCD.1 --> AaBCD1
Verwaltung und Inbetriebnahme von Snapsets
Jeder neu erzeugte Snapset besitzt eine eindeutige Snapset-Identifikation (siehe "Snapset-Identifikation"). Die Beschreibungen aller Snapsets eines Pubset werden im Snapset-Katalog hinterlegt und verwaltet. Der Snapset-Katalog wird im zugehörigen Pubset unter dem Namen $TSOS.SYSCAT.SNAPSET abgelegt und enthält folgende Informationen:
die Verarbeitungsumgebung für die Snapsets des Pubsets wie die Nutzung von remote Replikation und Angaben zum Save Pool
Beschreibung der einzelnen Snapsets mit Angaben wie Snapset-Identifikation, Erstellungsdatum und MNs der Snap-Units im lokalen Storage-System und ggf. auch der Snap-Units im remote Storage-System.
Der Snapset-Katalog wird, falls er noch nicht existiert, mit Erstellen des Snapsets eingerichtet. Der Snapset-Katalog liegt bei einem SM-Pubset auf der Volres des Control-Volume-Sets und bei einem SF-Pubset auf der zugehörigen Pubres.
Snapsets in und außer Betrieb nehmen
Bestehende Snapsets werden in der Regel beim Importieren des zugehörigen Pubsets in Betrieb genommen.
Vorhandene Snapsets werden nicht in Betrieb genommen, wenn das Subsystem SHC-OSD zum Zeitpunkt des Pubset-Imports noch nicht aktiv ist (insbesondere werden vorhandene Snapsets des Home-Pubsets beim Hochfahren des Systems nicht automatisch in Betrieb genommen). Sobald SHC-OSD aktiv ist, werden die Snapsets bei Aufruf des Kommandos SHOW-SNAPSET-CONFIGURATION nachträglich aktiviert.
Wenn Snapsets beim Import wegen Hardware- oder Konfigurationsproblemen nicht in Betrieb genommen werden können, dann verbleiben diese zunächst im Zustand „nicht zugreifbar“. Nach Fehlerbehebung können diese Snapsets mit dem Kommando CHECK-SNAPSET-CONFIGURATION wieder zugreifbar gemacht werden.
Beim Neuanlegen mit dem Kommando CREATE-SNAPSET wird ein Snapset automatisch in Betrieb genommen.
Dabei werden folgende Aktionen durchgeführt:
Snapset-Katalog öffnen (durch GCF)
alle Snap-Units zuweisen (ATTACH)
In einer Konfiguration mit remote Replikation werden die „passenden“ Snap-Units zugewiesen. Im Normalzustand bei aktiver remote Replikation sind das die Snap-Units im lokalen Storage-System. Bei getrennten Spiegeln erfolgt die Auswahl anhand des importierten Original-Pubsets:Beim Pubset am lokalen Storage-System werden nur die Snap-Units am lokalen Storage-System verwendet.
Beim Pubset am remote Storage-System werden nur die Snap-Units am remote Storage-System verwendet.
Unter VM2000 sind für die implizite Gerätezuordnung Randbedingungen zu beachten, siehe Abschnitt „Hinweis für VM2000“ im Kapitel "Snapset-Betrieb vorbereiten".
Snapset im Storage-System anlegen
CCOPY-Session für den Snapset aufbauen
Beim Exportieren des Pubsets werden die zugehörigen Snapsets außer Betrieb genommen. Die beim Importieren ausgeführten Aktionen werden in umgekehrter Reihenfolge durchgeführt.
Snapset löschen
Unabhängig von der Snap-Erstellung kann die Systembetreuung bzw. die HSMS-Administration für einen importierten Pubset einen vorhandenen Snapset auch explizit löschen:
/DELETE-SNAPSET PUBSET=A[,SNAPSET=*EARLIEST]
Hier wird der älteste Snapset des Pubsets A gelöscht.
Die Angabe SNAPSET=*EARLIEST kann auch entfallen (Voreinstellung).
Der zu löschende Snapset kann auch über seine Snapset-Identifikation oder als relative Angabe zum aktuellen Stand des Pubsets (mit -n, wobei -1 den jüngsten Snapset bezeichnet) angegeben werden. Mit dem Löschen eines Snapsets steht der entsprechende Sicherungsstand des Pubsets nicht mehr zur Verfügung. Gerade laufende Restore-Vorgänge für einen zu löschenden Snapset werden mit dem Löschen des Snapsets abgebrochen.
Im Betrieb mit ETERNUS kann jeweils nur der älteste Snapset gelöscht werden. Dies ist zu beachten, wenn ein zu löschender Snapset explizit über die Snapset-Id oder über das relative Alter angegeben wird.
Snapset-Betrieb beenden
Mit der Angabe SNAPSET=*ALL werden alle Snapsets gelöscht und der Snapset-Betrieb für den Pubset beendet. Dieser Aufruf beinhaltet folgende Maßnahmen:
alle Snapsets löschen
Snapset-Katalog schließen und löschen
Snapset-Limit des Pubsets auf Null setzen
Snapsets anzeigen
Das Kommando SHOW-SNAPSET-CONFIGURATION gibt für einen Pubset Informationen zu den jeweiligen Snapsets aus, siehe Handbuch „Kommandos“ [27]:
/SHOW-SNAPSET-CONFIGURATION PUBSET=<cat-id>,SNAPSET=*ALL
Dabei werden sowohl Pubset-globale als auch Snapset-spezifische Informationen angezeigt.
Falls der privilegierte Benutzer (Privileg TSOS, OPERATING, HSMS-Administrator) Informationen über einen bestimmten Snapset anfordert, werden zusätzlich die VSNs der Pubset-Volumes und die MNs der zugeordneten Snap-Units des lokalen Stroage-Systems ausgegeben (bei remote Replikation ggf. auch für das remote Storage-System).
Hinweise und Einschränkungen
Kein Snapset-Betrieb
Der Snapset-Betrieb für einen Pubset ist – wie alle anderen über SHC-OSD angebotenen Replikationsfunktionen – nicht verträglich mit DAB-Schreib-Caching für diesen Pubset. Das Kommando CREATE-SNAPSET wird bei DAB-Schreib-Caching abgewiesen.
Snapset-Betrieb und DRV-Spiegelung für einen Pubset schließen sich gegenseitig aus: Auf einem Pubset mit Snapset-Betrieb (Snapset-Limit ungleich 0) kann kein DRV-Betrieb aufgenommen werden und umgekehrt.
Snapset-Betrieb mit remote Replikation
Wenn Snapsets auch auf dem remote Storage-System betrieben werden sollen (siehe Abschnitt „Snapset-Betrieb bei Katastrophenschutz mit remote Replikation“ im Kapitel "Snapset-Betrieb vorbereiten"), sind folgende Einschränkungen zu beachten:
Die Snapset-Erzeugung auf dem remote Storage-System ist nicht möglich, wenn die remote Replikation unterbrochen ist (entweder mit dem Kommando HOLD-REMOTE-COPY oder verursacht durch unterbrochene Links), wenn die remote Spiegelplatte noch nicht synchronisiert ist oder bei asynchroner remote Replikation.
Wenn die Snapset-Erzeugung auf einem der beteiligten Storage-Systeme (lokal oder remote) scheitert, so wird auch auf dem anderen Storage-System kein Snapset erstellt.
Wenn der Zugriff auf die Platten des Pubsets dynamisch zwischen Source- und Target-System umgeschaltet wird (z.B. durch SHC-OSD-Kommandos), dann wird der Zugriff auf die dem Pubset zugeordneten Snapsets nicht automatisch mit umgeschaltet.
Das Kommando ADAPT-SNAPSET-ACCESS stellt sicher, dass die zugeordneten Snapsets nach einer solchen Umschaltung weiter zur Verfügung stehen, ohne dass der Pubset exportiert werden muss.Beim Kommandoaufruf wird geprüft, ob der Zugriff auf die zugeordneten Snapsets im gleichen Controller erfolgt wie der Zugriff auf die Platten des Pubsets. Wenn dies nicht der Fall ist, dann wird die Umschaltung für die dem Pubset zugeordneten Snapsets nachgebildet:
Die aktuell zugeschalteten Snapsets werden außer Betrieb genommen.
Anschließend werden die Snapsets des lokalen Controllers zugeschaltet.
Betriebsmittelengpass und seine Folgen
Der benötigte Speicherplatz für die zu sichernden Originaldaten wird normalerweise aus dem Save Pool bereitgestellt. Hinweise dazu und die möglichen Folgen bei einem Überlauf finden Sie im Abschnitt „Snapset-Betrieb vorbereiten".
Zur Vermeidung eines hohen Speicherbedarfs für die zu sichernden Originaldaten sollten folgende Maßnahmen getroffen werden:
keine Paging-Dateien in Pubsets mit Snapset-Betrieb erzeugen
den Pubset möglichst wenig mit dem Softwareprodukt SPACEOPT reorganisieren
Änderung der Pubset-Konfiguration
Bevor eine der folgenden Änderungen der Pubset-Konfiguration durchgeführt wird, muss der Snapset-Betrieb beendet werden (bedeutet Löschen aller Snapsets):
vor dem Umbenennen eines Pubsets
vor dem Überführen eines SF-Pubsets in einen Volume-Set eines SM-Pubsets
vor dem Wechsel auf andere Pubset-Platten, d.h. beim Übergang von K- auf NK-Format, beim Wechsel von CKD- auf FBA-Platten oder bei einem physikalischen Umzug mit FDDRL (Save/Restore)
Bei Vergrößerung des Pubsets um weitere Platten muss auch die Menge der passenden Snap-Units entsprechend erweitert werden (siehe Abschnitt „Snapset-Betrieb vorbereiten").
Bei der Reduzierung des Pubsets um Platten werden vorhandene Snapsets ungültig. Sie können nicht mehr zur Rekonstruktion herangezogen werden. Sie werden nach einer Neuinitialisierung der remote Platten beim nächsten Importieren des Pubset aus dem Snapset-Katalog entfernt. Vorhandene Snapsets müssen daher vor dem Herauskonfigurieren von Platten mit HSMS gesichert werden, falls die dort abgelegten Daten noch benötigt werden. Unmittelbar nach der Konfigurationsänderung sollte ein neuer Snapset erzeugt werden, damit die Rekonstruktion von Dateien und Jobvariablen sowie des gesamten Pubsets möglich bleibt.
Migrierte Dateien
Damit migrierte Dateien nach der Rekonstruktion von Snapsets noch benutzbar sind, müssen die zugehörigen Bänder noch vorhanden sein. Sie dürfen nicht freigegeben oder schon neu verwendet worden sein.
Wenn vorhandene Snapsets einen Zeitraum von n zurückliegenden Tagen für die Rekonstruktion abdecken, dann sollte die Rekonstruktion der migrierten Dateien mit HSMS stets nur für einen Zeitraum vor diesen n Tagen durchgeführt werden.