Snapset-Betrieb vorbereiten

Den Snapset-Betrieb für einen Pubset aufzunehmen bedeutet, dass für den Pubset Kopien (Sicherungen) auf Snapsets erstellt werden, die für die Rekonstruktion von Dateien bzw. Jobvariablen oder des gesamten Pubsets zur Verfügung stehen.

Begriffe

Snap-Unit

Die lokalen Replikationsfunktionen der Storage-Systeme erstellen einen „Snapshot“ einer logischen Unit (ggf. auch mehrere). Der Snapshot, Snap-Unit genannt, ist eine logische Kopie der Original-Unit zu einem bestimmten Zeitpunkt („Point-in-Time-Kopie“): Während die Daten auf der Original-Unit verändert werden, behält die Snap-Unit den Stand der Daten zum Zeitpunkt der Snapshot-Erstellung.

Für den Snapset-Betrieb müssen die dafür geplanten Snap-Units auf Thin Devices (TDEV) oder Flex Volumes (FDEV) vorab mit dem Dienstprogramm VOLIN (siehe „Dienstprogramme“ [15]) initialisiert werden. Als VSN für diese Volumes wird die Sondernotation S#<mn> erwartet, z.B. S#5234. <mn> ist dabei die Geräte-Mnemonic. Aufgrund der Flexibilität wird diese Art der Snap-Units empfohlen.

Für den Snapset-Betrieb können auch speziell konfigurierte Units, sog. Snap-Units oder auch Snap-Device-Volumes (SDVs) verwendet werden. Diese werden in der Regel von einem qualifizierten Techniker direkt am Storage-System eingerichtet. Original-Unit und Snap-Unit müssen dabei im selben Storage-System liegen.

Im BS2000 werden die Snap-Units wie normale Plattengeräte (Typ D3435) generiert mit gleicher Kapazität wie die jeweilige Original-Unit.

Save Pool

Der tatsächlich benötigte Speicherplatz für die zu sichernden Originaldaten wird ggf. aus einem sogenannten Save-Pool bereitgestellt. Im Speichersystem werden Save Pools mit entsprechender Kapazität konfiguriert.

Die Realisierung von Save-Pools ist abhängig vom Storage-System:

ETERNUS DX/AF Systeme

• im S#-Volume Betrieb
  Hier gibt es keinen separaten Save-Pool.
  Der benötigte Speicherplatz wird hier aus den entsprechend zugeordneten Snap-Units bedient, die der Überlaufkontrolle des jeweiligen „Thin Provisioning Pool" unterliegen.
• im SDV-Betrieb
  Hier gibt es nur einen einzigen Save-Pool für alle Snapsets.
  Ein Save-Pool wird im Storage-System mit geeigneter Kapazität konfiguriert. Daraus wird der tatsächlich benötigte Speicherplatz für die zu sichernden Originaldaten bereitgestellt.
  Bei Überlauf des Save-Pools sind alle Snapsets korrupt, die hier Speicherplatz belegen. Die Funktionen von SHC-OSD zur Überwachung von Save Pools sollten deshalb hier dringend genutzt werden.

Hinweise zum Betrieb mit Save-Pool:

Der tatsächlich benötigte Speicherplatz (für die zu sichernden Originaldaten) wird dabei in der Regel aus einem speziell dafür vorgehaltenen Speicherbereich auf dem Storage-System, dem sogenannten Save-Pool, bestritten. Die benötigte Kapazität eines Save-Pools ist von folgenden Faktoren abhängig:

• Datenvolumen der Anwendung für die Snapsets erzeugt wurden
• Anzahl der Snap-Sessions pro Original
• Änderungsvolumen auf dem Original (und den zugehörigen Snap-Units)

Beim Löschen eines Snapsets wird der jeweilige Bereich im Save-Pool wieder freigegeben.

Save-Pool / Thin-Pool Monitoring

Zur Überwachung des Füllgrades eines Save-Pools bzw. Thin-Pools stellt SHC-OSD entsprechende Monitoring-Funktionen zur Verfügung. Bei Erreichen oder Ändern gewisser Grenzwerte werden Warnmeldungen an der Konsole ausgegeben.
Die Systemadministration sollte in jedem Fall angemessen darauf reagieren und wieder Platz auf dem Save-Pool schaffen bzw. diesen bei Bedarf auch erweitern. Die Grenzwerte selbst werden am Storage-System oder auch in der SHC-OSD Parameterdatei eingestellt.

ACHTUNG!
Bei einem Überlauf gehen die bestehenden Snapsets verloren.
Konkret gehen die jeweiligen Snap-Sessions in den Zustand „FAILED“ und können anschließend nur noch gelöscht werden.

Beispiel für die Vorbereitungen

Bevor der Snapset-Betrieb für einen Pubset aufgenommen werden kann, sind entsprechende Vorbereitungen zu treffen. Die Vorgehensweise soll an folgendem Beispiel veranschaulicht werden.

• Ausgangssituation und Bedarfsplanung

  Der Pubset A besteht aus 8 Platten (PUBA00 bis PUBA07). Er soll an jedem Arbeitstag zweimal (z.B. mittags und abends) gesichert werden. Der Zugriff auf die Sicherungen der letzten 6 Arbeitstage soll gewährleistet sein.

  Für 2 x 6 Pubset-Sicherungen müssen dann 12 Snapsets zur Verfügung stehen. Pro Snapset wird die gleiche Anzahl an Snap-Units benötigt wie die Anzahl der Platten in Pubset A. Insgesamt werden 8 x 12 = 96 Snap-Units benötigt.

• Snap-Units im Storage-System bereitstellen

  Die benötigten 96 Snap-Units sind im selben Storage-System wie die Original-Platten des Pubset A mit gleichem Typ und gleicher Größe bereitzustellen.
  Wenn bereits eine Pubset-Erweiterung abzusehen ist, sollten auch dafür schon zusätzliche Snap-Units in ausreichender Zahl eingerichtet werden.

   ETERNUS DX/AF Systeme können mit vorkonfigurierten Snap-Units oder S#<mn> Volumes betrieben werden. Siehe „Begriffe".

• Snap-Units in BS2000 konfigurieren

  Alle 96 Snap-Units müssen wie normale Platten (Typ D3435) in die Hardware-Generierung der beteiligten BS2000-Systeme aufgenommen werden, praktisch also in alle Hardware-Generierungen, in denen auch die Original-Platten des Pubsets A eingetragen sind (siehe Handbuch „Systeminstallation“ [55]).

  An SU /390 können die Platten auch im laufenden Betrieb in die aktive I/O-Konfiguration aufgenommen werden.
  Die Aufnahme von emulierten Platten D3435 in die X2000-Konfiguration einer SU x86 ist im Handbuch „Bedienen und Verwalten“ [57] beschrieben.

  Hinweis für VM2000

  Im Storage-System eingerichtete Snap-Units werden von VM2000 auch als Snap-Units erkannt. Sie werden automatisch beim Pubset-Import zugeschaltet und unter VM2000 implizit der VM zugeordnet, wenn die VM das Privileg AUTO-SNAP-ASSIGNMENT besitzt. Eine VM erhält beim Initialisieren mit dem VM2000-Kommando CREATE-VM standardmäßig dieses Privileg. Es erlaubt dem Gastsystem auf der VM, sich die Snap-Units eines Snapsets implizit zuzuordnen, ohne dass VM und Gerät für die implizite Gerätezuordnung vorbereitet sind (d.h. das VM-Privileg und das Geräte-Attribut ASSIGN-BY-GUEST sind in diesem Fall nicht notwendig).

  Ausnahme

  Werden S#<mn> Volumes als Snap-Units verwendet, dann werden diese von VM2000 nicht als Snap-Units erkannt und auch nicht angezeigt. Sie können trotzdem einer VM mit dem VM-Privileg AUTO-SNAP-ASSIGNMENT implizit zugeordnet werden.

• Snapset-Limit setzen und ggf. Save Pool zuweisen (in BS2000)

  Das Snapset-Limit ist im SVL der Pubres eingetragen. Es legt fest, wie viele Snapsets maximal für den Pubset zulässig sind. Bei einem Pubset ohne Snapset-Betrieb ist das Snapset-Limit 0.
  Da für den Pubset A maximal 12 Snapsets angelegt werden sollen, setzt die Systembetreuung das Snapset-Limit auf 12:

  /SET-PUBSET-ATTRIBUTES PUBSET=A,SNAPSET-LIMIT=12

Snapset-Betrieb bei Katastrophenschutz mit remote Replikation

Wird der Pubset A wegen Katastrophenschutz in einem lokalen Storage-System und in einem remote Storage-System betrieben, ist für den Snapset-Betrieb Folgendes zu beachten:

• Im Normalfall werden die Snapsets nur im lokalen Storage-System eingerichtet. Sie stehen bei Ausfall des lokalen Storage-Systems nicht mehr zur Verfügung.

• Sollen die Snapsets für den Katastrophenfall auch im remote Storage-System zur Verfügung stehen, müssen sie in beiden Storage-Systemen erzeugt werden. Dazu muss im remote Storage-System die gleiche Anzahl Snap-Units wie im lokalen Storage-System bereitgestellt und und in die Hardware-Generierung der beteiligten BS2000-Systeme aufgenommen werden.

  Zusätzlich muss die Systembetreuung die Verarbeitungsumgebung für die Snapsets entsprechend einstellen:

  /SET-SNAPSET-PARAMETER PUBSET=A,REMOTE-COPY=*YES

  Bei einer Umschaltung des Plattenzugriffs zwischen Source- und Target-Controller 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:

  /ADAPT-SNAPSET-ACCESS PUBSET=A