Dieser Artikel ist vor allem für die Nutzer interessant, deren IBM-Power-Systeme mit mindestens einer IBM i LPAR im SAN (Storage Area Network) liegen, nicht jedoch für die, die interne Festplatten oder SSDs besitzen und bei dieser Technologie bleiben möchten. Von besonderer Bedeutung ist er jedoch für die Nutzer, deren Storage-Systeme von einem IBM SVC (SAN Volume Controller) verwaltet werden oder die erhöhte Anforderungen an robuste Hochverfügbarkeitslösungen stellen.

Der bcStorageManager ist eine Lösung der Blue-Consult GmbH, um die häufig gewünschte Integration von IBM i in die SAN-Architektur sicher, einfach und bequem umsetzen zu können.

Die Kernaufgaben des bcStorageManager sind folgende:

  1. Erstellen und Verwalten von OS/400-Clone-&-Sandbox-Systemen mittels Storage Snapshots oder FlashCopy
  2. Durchführung von Sicherungen mit und ohne BRMS (OS/400 Backup Recovery Media Services) auf Clone-Systemen, um einen uneingeschränkten 24*7-Betrieb sicherstellen zu können
  3. Unterstützung bei Desaster-&-Recovery-Szenarien wie Rechenzentrums- oder Systemumschaltung, Wiederherstellung gesamter Systeme über FlashCopy, Unterstützung bei der Live Partition Mobility (LPM) usw.
  4. Vereinfachung der Administration sowie Storage-Monitoring-&-Performance-Analysen aus Sicht von OS/400, sodass ein IBM-i-Administrator sich nicht mit den SVC- oder Storage-Systemen beschäftigen muss.

Abbildung 1: Vorteile des Flash-Copy-Systems Quelle: BLUE Consult

Zunächst soll geklärt werden, um was es sich bei einer FlashCopy (FC) oder einem Snapshot (SNAP) handelt. Eine FlashCopy ist eine Storage-Funktion, die ein Duplikat von Daten in Sekundenbruchteilen erstellt. Dies kann mittels einer Disk (LUN) oder der für IBM i üblichen Vielzahl von Disks erfolgen. Um die FlashCopy-Zeiten für alle Disks genauestens einhalten zu können, werden alle FC-Relationen in einer Konsistenzgruppe angelegt. Eine FC-Relation besteht aus einer Source und einer Target Disk, und durch ihren Start beginnt der Kopierprozess. Moderne Storage-Systeme wie IBM SVC oder Storwize lassen sofort nach dem Start der FC einen lesenden wie auch einen schreibenden Zugriff auf die Kopie zu. Sollte ein benötigter Datenblock noch nicht kopiert sein, wird er einfach vom Original gelesen. Die Target Disks benötigen allerdings exakt so viel Speicherkapazität wie ihre Originale, es sei denn, es werden auf den Storage-Systemen die Funktionen Datenkompression oder Datendeduplikation verwendet, die von den meisten IBM-Systemen unterstützt werden. Um den Nachteil der hohen Kapazität kompensieren zu können, wird die SNAP-Technologie eingesetzt. Hierbei werden erst Daten kopiert, wenn diese sich auf der Source oder der Target Disk tatsächlich ändern. Dies spart zwar eine Menge Speicherplatz, jedoch zu dem Preis, dass die Kopie immer vom Original abhängig ist. Ist das Original verlorengegangen, dann auch die Kopie.

Die Vorteile liegen auf der Hand. Wenn es möglich ist, zu jedem Zeitpunkt eine exakte Kopie der Daten zu erstellen, dann können diese für (Tape-)Sicherungen verwendet werden. Programmiert werden kann, indem der aktuellste Datenbestand in Form von Sandboxen zur Verfügung gestellt wird, wenn jederzeit das K-Fall-Szenario simuliert werden kann und wenn Clone auf der DR-LPAR eines anderen Systems bzw. Standorts angehängt und getestet und so auf die mühselig geplanten DR-Test-Wochenenden verzichtet wird. Da aus Gründen der Performance meist kein Mangel an Storage-Kapazitäten herrscht, können viele FC-Kopien am Tag erstellt werden, und es kann infolgedessen ein eventueller Datenverlust drastisch reduziert werden (RPO = Recovery Point Objective). Vier bis acht Kopien am Tag zu erstellen ist nicht unrealistisch und sichert gut gegen Benutzer- oder Datenfehler ab.

Abbildung 2: Mit Clone arbeiten Quelle: BLUE Consult

Mit dem Einsatz von FC/SNAP ergibt sich hier ein weiterer Vorteil. Wer einmal eine Komplettsicherung (21er-Sicherung) nach einem K-Fall zurückspielen musste, weiß, wie lange das dauert und dass die Zeit meist von der vorherigen Schätzung drastisch abweicht. In der gesamten Phase der Wiederherstellung ist das System offline. Hier kann Reverse FlashCopy helfen. Die FlashCopy-Relation wird einfach umgekehrt und so zurück kopiert. Von der FC ist es bereits bekannt, dass die Kopie sofort nach dem Start einsatzbereit ist. Das gilt auch für Reverse FlashCopy, sodass eine Wiederherstellung selten mehr als wenige Minuten Zeit in Anspruch nimmt.

Nun soll aufgezeigt werden, wie der bcStorageManager hilft, Systeme mittels FlashCopy zu erzeugen, zu sichern oder als Sandbox-Systeme verschiedensten Tests zur Verfügung zu stellen. Der bcStorageManager verwaltet Rollen sowie deren Eigenschaften und Funktionen. Das „normale“ System besitzt die Rolle *LIVE und beschreibt Ihr gewohntes Produktionssystem (siehe Abbildung 1 linke LPAR). Ein Umschaltsystem für K-Fälle hat die Rolle *DR, und diese soll den Umschaltprozess unterstützen und sicherstellen, dass nicht sofort nach einer Umschaltung alle Applikationen starten, sondern Schritt für Schritt geprüft und bei Erfolg explizit freigegeben werden können. Systeme, die mit Hilfe von FlashCopy oder SNAP von den *LIVE oder *DR abgeleitet werden, entsprechen der Rolle *CLONE (siehe Abbildung 1 rechte LPAR). Damit ein Clone erfolgreich starten kann, muss dieser einem verfügbaren System oder LPAR vom bcStorageManager zugewiesen und hinsichtlich IP-Adressen, TCP/IP-Server, Leitungsbeschreibungen, Tape-Konfigurationen usw. angepasst werden. Der bcStorageManager übernimmt diese Vielzahl von Konfigurationen automatisch und sendet dem Live-System den jeweiligen Status, unabhängig davon, ob die Clone-LPAR auf dem eigenen oder auf einem anderen System existiert bzw. mit Live Partition Mobility die Systeme zeitweise wechselt. Ist die Clone-LPAR erfolgreich gestartet, sind eventuelle Rollbacks abgeschlossen und sind Zugriffspfade wiederhergestellt, kann sie auf Wunsch mit dem Sichern beginnen. Durch weitere bcStgMgr-Konfigurationen könnte der Clone zu einem Sandbox-System modifiziert werden. Viele Eigenschaften können im bcStorageManager parametrisiert werden.

Abbildung 3: Das Ergebnis der Sicherung kann eingesehen werden Quelle: BLUE Consult

Mit den Befehlen CRTCLONE und CHGCLONE können Rollen für Clone-Systeme erstellt bzw. modifiziert werden. Der Administrator wird hierbei durch ein selektives CL-Prompt unterstützt, und die Auswahl von Parametern wird durch intelligente Filter reduziert. In den meisten Fällen steht die F4-Taste zur Verfügung, um sich eine mögliche Auswahl anzeigen zu lassen. Mit dem Befehl DLTCLONE können nicht mehr benötigte Rollen gelöscht werden, und es kann die Laufzeitumgebung bereinigt werden. Alle wichtigen Befehle sind übersichtlich in einem Hauptmenü hinterlegt. Diese Tätigkeiten werden in der Regel einmalig nach einer etwa einstündigen Installation und Grundkonfiguration durchgeführt. Die Hauptsache ist natürlich das Starten eines Clone mit dem Befehl STRCLONE. Soll der Clone zudem sichern, so wird der Parameter SAVE auf *YES gesetzt (STRCLONE SAVE(*YES)). Dieser kann auch so in Ihren Job Scheduler im OS/400 oder in Ihrem Sicherungsprogramm gegen den bekannten STRBKUBRM-Befehl ausgetauscht werden. Schon wird die Sicherung auf dem per FlashCopy generierten Clone-System ausgeführt, und sie belastet nicht mehr Ihr lokales System. Solange BRMS auf dem Clone-System sichert, ist auf dem Live-System das Arbeiten mit BRMS untersagt, damit Ihre Datenträgerbestände geschützt sind. Der bcStorageManager steuert BRMS und seine Netzwerkfunktionen (Lizenzprogramm BRMS Netzwerk ist erforderlich) automatisch mit. Die Clone-LPAR meldet sich nach Abschluss der Sicherung zurück und überträgt die Sicherungsdaten an die Live-LPAR gefolgt von einer anschließenden Prüfung der BRMS-Datenbank auf deren Vollständigkeit. Nach erfolgreicher Prüfung kann auf Wunsch BRMS Maintenance ausgeführt und das Sicherungsergebnis mittels einer App analysiert werden (Abbildung 3).

Besitzen Sie mehr als ein System (zum Beispiel ein Backup-System), ist es wünschenswert, auf jedem System eine Clone-LPAR zu konfigurieren. Denn damit können Sie durch das Starten der FlashCopy jeden Tag das Backup-System testen. Sollte ein Systemwechsel vollzogen werden, wird automatisch am entfernten Standort gesichert. Sie können so viele Clones gleichzeitig starten, wie Clone-LPARs zur Verfügung stehen. Allerdings heißt das nicht, dass Sie nicht mehr FlashCopys erzeugen und testen können. So sichert zum Beispiel eine Clone-LPAR über viele Stunden, während eine zweite Clone-LPAR alle zwei Stunden mit einem neu erzeugten Clone verbunden und zum Test gestartet wird. Ein möglicher Datenverlust bei einer Katastrophe könnte in diesem Fall zwei Stunden statt 24 Stunden tangieren– eine echte Bereicherung bei sehr wenig Administrationsaufwand.

Zu beachten ist bei FlashCopy-Praktiken, dass eine FlashCopy im beruhigten Systemzustand ausgeführt werden sollte. Doch übernimmt das der bcStorageManager-Start-FC-Befehl STRCLONE FREEZE(*YES) für Sie. Im Hintergrund wird der OS/400-Befehl CHGASPACT ASPDEV(*SYSBAS) OPTION(*SUSPEND) gesteuert ausgeführt. Alle Transaktionen werden möglichst beendet, und neue Transaktionen werden in dieser Zeit nicht zugelassen. Der Hauptspeicher wird auf die Platte geschrieben, sodass ein möglichst konsistenter Zustand zum Zeitpunkt der FlashCopy existiert.

Drei Punkten sollten Sie besondere Aufmerksamkeit widmen:

Gelingt das Beruhigen nicht, dann finden auf der Clone-LPAR Rollbacks statt, bzw. es werden im IPL-Schritt Speicherwiederherstellung die Daten berichtigt, sodass die Datenbank wieder konsistent ist. Im Vergleich zu Save While Active (SWA) wird das häufig in Kauf genommen, da bei einem SWA-Timeout wichtige Dateien gar nicht gesichert werden.

Das Einfrieren Ihres Systems mag wohl für die Sicherung sehr sinnvoll sein, doch werden es die Anwender nicht dulden, dass dies zu jeder Stunde passiert, da sie meist länger als üblich auf eine Sanduhr ihres Bildschirms schauen. Über den bcStorageManager können Sie für jede Stunde die maximale Freeze-Zeit innerhalb einer Woche konfigurieren. Die Reduzierung der Freeze-Zeiten geht jedoch zulasten der FlashCopy-Qualität.

Ist es für Sie unumgänglich, Journal Receiver für die Datenbankwiederherstellung oder Revision zu sichern, hilft Ihnen die Sicherung auf der Clone-LPAR nicht. Nach jedem IPL entwickeln sich die Journale auseinander, und sie sind für eine Wiederherstellung mit RSTLIB und eine anschließende APYJRNCHG unbrauchbar.

Einen Ausweg aus diesem Dilemma verschafft die Kombination bcStorageManager mit Visionsolutions MIMIX4Flash. MIMIX ist als bewährtes Replikations-Tool für Datenbanken und andere Objekte im OS/400 über Jahre etabliert. Besonderes viel Erfahrung besitzt die Software darin, bei abnormalen Systembeendigungen exakt zu wissen, welche Transaktionen auf den Target-Systemen noch ausstehen. Genau das wird in Verbindung mit FlashCopy ausgenutzt. Der bcStorageManager startet die Konvertierung zu einem MIMIX-Target-System nach dem ersten IPL der Clone-LPAR. MIMIX analysiert alle offenen Transaktionen und repariert diese nach Bedarf. Ist die Reparatur der Datenbank abgeschlossen, kann die MIMIX-Replikation bis zur nächsten FlashCopy wie ein Spiegel verwendet werden. Folglich ist es nicht mehr erforderlich, bei sehr hohen SLAs (RPO weniger als zwei Stunden) eine Vielzahl von FC/SNAPs auszuführen. Auch entfällt weitestgehend die Administration von MIMIX, da die gesamte Kopie in regelmäßigen Abständen mit FlashCopy aktualisiert wird. Ein weiterer Vorteil besteht darin, dass die Journalketten erhalten bleiben. Sie können die Journal Receiver auf dem Clone-System sichern und für die Wiederherstellung der Daten später verwenden.

Mit einer Kombination aus Hardware- und Software-Lösung haben Sie wohl den höchsten Abdeckungsgrad für Fehlersituationen aller Art. Der administrative Aufwand ist in dieser Kombination minimal. Sie verfügen sowohl über eine Site Awareness durch eine Hardware-Spiegelung mit zyklischen Kopien wie auch als Antwort auf Benutzer-, Schnittstellen- oder Datenfehler eine transaktionsorientierte Spiegelung, die in regelmäßigen zeitlichen Abständen durch eine FlashCopy aktualisiert wird.

www.blue-consult.de