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 werden speziell konfigurierte Units, sog. Snap-Units oder auch Snap-Device-Volumes (SDVs) benötigt. 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 einer Kapazität größer gleich der jeweiligen Original-Unit.

• Neue ETERNUS Systeme (ab DX S3 und AF):
  Mit SHC-OSD V13.0 sind hier Snaps ohne speziell konfigurierte SDVs möglich.
  Für den Snapset-Betrieb müssen dazu die 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.

• EMC Systeme mit TimeFinder/SnapVX:
  Bei diesen Systemen gibt es keine speziell konfigurierten SDVs mehr.
  Jedes konfigurierte und in BS2000 generierte Gerät kann als Snap-Unit verwendet werden.
  Für den Snapset-Betrieb müssen dann die geplanten Snap-Units vorab mit dem Dienstprogramm VOLIN (siehe Handbuch „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.

Save Pool

Der tatsächlich benötigte Speicherplatz für die zu sichernden Originaldaten wird nötigenfalls aus einem sogenannten Save Pool bereitgestellt. Save Pools werden im Storage-System mit einer geeigneten Kapazität konfiguriert.

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

ETERNUS Systeme

• im SDV-Betrieb
  Hier gibt es nur einen einzigen Save-Pool für alle Snapsets.
  Der benötigte Speicherplatz wird zunächst aus den jeweiligen Snap-Units bedient. Erst wenn deren Kapazität erschöpft ist (ca. 10% der Original-Unit) wird Speicherplatz auf dem Save-Pool belegt.
  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.
  

• 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.
  

EMC Systeme

• mit TimeFinder/Snap
  Hier sind auch dedizierte Save Pools möglich.
  Der benötigte Speicherplatz wird sofort aus dem zugeordneten Save Pool bestritten.
  Bei Erreichen des kritischen Füllgrades eines Save Pools wird implizit versucht den jeweils ältesten Snapset zu löschen.
  Bei Überlauf des Save Pools sind nur die Snapsets des jeweilgen Save Pools korrupt.
  Durch die Nutzung dedizierter Save Pools kann also eine gewisse Abschottung erreicht werden, indem beispielsweise die Snapsets bestimmter Anwendungen, die mit unterschiedlichen Pubsets arbeiten, verschiedenen Save Pools zugeordnet werden.

• mit TimeFinder/SnapVX
  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.

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 Monitoring

Zur Überwachung des Füllgrades eines Save 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.

  In VMAX3 gibt es keine speziell konfigurierten Snap-Units. ETERNUS Systeme können je nach Modell 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]).

  In VMAX3 müssen die Snap-Units als BS2000-Volumes mit der Sondernotation S#<mn> zur Verfügung gestellt werden, siehe „Begriffe".

  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

  Für Symmetrix (Funktion TimeFinder/Snap) sind mehrere Save Pools möglich, siehe Abschnitt „Begriffe". Wenn also für den Pubset A beispielsweise der spezielle Save Pool SPA auf dem Storage-System eingerichtet wurde, dann kann die Systembetreuung diesen Save Pool nun zuweisen:

  /SET-SNAPSET-PARAMETER PUBSET=A,SAVE-POOL-NAME=SPA

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 (ggf. mit dem gleichen Save Pool) 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(RA-GROUP=*UNIQUE)

  Beim Betrieb mit Symmetrix/VMAX3 sind folgende Besonderheiten zu beachten:

  • Die beteiligten Storage-Systeme Symmetrix/VMAX3 (Source- und Target-System) müssen bzgl. der Funktionen TimeFinder/Snap bzw. TimeFinder SnapVX homogen sein. Eine remote Replikation zwischen Symmetrix und VMAX3 ist deswegen nicht möglich.

  • Beim Einsatz von Concurrent SRDF ist die RA-Group des jeweiligen remote Storage-Systems anzugeben.

  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