VON SABINE JORDAN

Metro Mirror / Global Mirror / FlashCopy

Metro Mirror ist eine synchrone Remote Copy Verbindung zwischen zwei Volumes gleicher Größe auf externen Storage Systemen. Solange das sekundäre Volume verfügbar ist, wird jede Schreiboperation, die an das primäre Volume geschickt wird, erst dann als erledigt an den Host zurückgemeldet, wenn sie im Schreibcache des primären UND des sekundären Storagesystems bestätigt wurde. Es erfolgt hier also eine Spiegelung von Schreibvorgängen, die durch das Storagesystem durchgeführt und kontrolliert wird. IBM i „weiß“ von dieser Spiegelung erst einmal nichts.

Global Mirror ist eine asynchrone Remote Copy Verbindung zwischen zwei Volumes gleicher Größe auf externen Storage Systemen. Jede Schreiboperation wird hier zum Host zurückgemeldet, wenn sie auf dem primären Storagesystem angekommen ist. Zu einem späteren Zeitpunkt (also asynchron) wird dann dieser Schreibvorgang zusätzlich vom primären zum sekundären Storage System geschickt. Global Mirror kann damit über größere Distanzen eingesetzt werden also Metro Mirror – garantiert aber nicht, dass jede abgeschlossene Transaktion der primären Seite auch auf der sekundären Seite vorhanden ist. Auch hier wird die Spiegelung der Daten vom Storage System durchgeführt und kontrolliert.

FlashCopy bietet die Möglichkeit, von einer oder mehrere Volumes eine Point-in-Time-Kopie innerhalb EINES externen Storage Systems zu erstellen. Im Gegensatz zu Metro Mirror und Gobal Mirror, die in erster Linie für Hochverfügbarkeit und Disaster Recovery genutzt werden, wird FlashCopy vor allem zur Erzeugung von Klonen (zum Beispiel für Testsysteme oder Business Intelligence Auswertungen) und als Grundlage für Datensicherungen, die nicht direkt auf dem Produktivsystem durchgeführt werden sollen, eingesetzt. Eine FlashCopy Beziehung kann so aufgesetzt werden, dass alle Daten vom Sourcevolume im Hintergrund zum Targetvolume übertragen werden (dieses Verfahren – background copy – wird normalerweise verwendet, wenn die Kopie längerfristig bestehen soll oder wenn Stressoder Perfomancetests mit der Kopie durchgeführt werden sollen). Alternativ kann das no-copy Verfahren verwendet werden (wenn die Kopie nur kurzfristig benötigt wird – zum Beispiel für eine Datensicherung) – dabei werden einzelne Speicherbereiche nur dann vom Sourcevolume zum Targetvolume kopiert, wenn entweder vom Targetsystem eine Änderung des entsprechenden Speicherbereiches erfolgt, oder bevor vom Sourcesystem eine Änderung durchgeführt wird. Um bei einer no-copy-Verbindung Plattenplatz zu sparen, können die Targetvolumes als thin-provisioned oder space-effi cient angelegt werden – sie belegen dann nicht den gleichen Platz wie die Sourcevolumes.

Im Folgenden werden einige beispielhafte Konfigurationen dargestellt, in denen diese Techniken genutzt werden.

V7000 mit Metro Mirror und PowerHA für IBM i

In einer Umgebung mit V7000 kann Hochverfügbarkeit mit IBM i und PowerHA durch die Verwendung von Metro Mirror realisiert werden. Das Produktionssystem erhält einen System-ASP, der in der primären V7000 konfiguriert ist. Dort liegen das Betriebssystem und Betriebssystemnahe Objekte wie Lizenzprogramme, Benutzerprofile usw. Zusätzlich wird ein iASP definiert, in dem die Anwendung und die Daten liegen. Für das Backup- System wird eine entsprechende Konfiguration (System-ASP und iASP) auf der sekundären V7000 vorgenommen. Zwischen den LUNs des primären iASP und des sekundären iASPs wird auf der V7000 Metro Mirror definiert. Damit wird sichergestellt, dass die Daten des Produktions-iASP identisch auf dem Backup-iASP geschrieben werden.

PowerHA für IBM i kontrolliert diese Umgebung – wenn zum Beispiel ein kontrolliertes Umschalten auf das Backup-System erfolgt, so „spricht“ PowerHA über eine ssh- Verbindung mit der V7000 und sorgt dafür, dass nicht nur IBM i Clustering die Rollen tauscht – sondern auch Metro Mirror in der Richtung umgedreht wird.

V7000 FlashCopy und PowerHA für IBM i

FlashCopy wird in der Praxis mit PowerHA für IBM i in erster Linie verwendet, um den Einfluß von Datensicherungen auf die Produktionsumgebung möglichst gering zu halten. Dabei wird zuerst der iASP auf dem Produktionssystem über den Befehl CHGASPACT „eingefroren“. In diesem Zustand können keine neuen Transaktionen gestartet werden, für laufende Transaktionen wird versucht, eine Transaktionsgrenze zu erreichen und der Hauptspeicherinhalt wird physisch auf die Platten des iASP geschrieben. Die Dauer dieses Vorgangs kann begrenzt werden – entweder läuft der Quiesce in dieser Zeit komplett durch und über einen Befehl auf der IBM i Umgebung kann der FlashCopy auf der V7000 ausgelöst werden – oder die Zeit läuft vorher ab. Auch in diesem Fall kann ein FlashCopy ausgelöst werden – das Aktivieren des iASP an der Sicherungs-Partition wird dann länger dauern als bei einem erfolgreichen Quiesce – aber immer noch schneller sein als komplett ohne Quiesce. Nachdem der FlashCopy erfolgt ist, wird das Produktionssystem über einen weiteren CHGASPACT wieder freigegeben und die Anwender können normal weiterarbeiten. Der iASP wird in der Sicherungs- Partition angehängt und dort erfolgt dann die Datensicherung. Nach erfolgter Datensicherung kann die FlashCopy-Verbindung auf der V7000 durch einen weiteren Befehl von PowerHA wieder aufgelöst werden.

SVC und LUN Level Switching mit PowerHA für IBM i

LUN Level Switching ermöglicht es, einen einzelnen iASP zwischen zwei Systemen hin und her zu schalten. Hier wird also keine Kopie  auf einem sekundären Storage- System erzeugt, sondern nur mit einer einzelnen Kopie gearbeitet. In einer SVC-Umgebung kann trotzdem sichergestellt werden, dass das Storage System nicht zu einem Single Point of Failure wird.

Im dargestellten Beispiel wirdsomit die Storage-Verfügbarkeit von der Server-Verfügbarkeit entkoppelt. PowerHA sorgt über LUN Level Switching für die Verfügbarkeit des Servers, während der SVC durch die Spiegelung zwischen den angeschlossenen Storage-Systemen für die Verfügbarkeit im Storage- Umfeld sorgt. Fällt eines der angeschlossenen Storage-Systeme aus,
so bemerkt die Server-Infrastruktur diesen Ausfall nicht. Fällt hingegen der Produktivserver aus, so wird über PowerHA eine Umschaltung auf das Backup-System vorgenommen und auch mit dem SVC kommuniziert, um dort zum Beispiel für die betroffenen LUNs eine Änderung der Host-Zuordnung vorzunehmen.

Voraussetzungen für die Verwendung von SVC / V7000 Metro Mirror, Global Mirror oder FlashCopy im Zusammenspiel mit PowerHA für IBM i sind:

• IBM i 7.1 mit Technology Refresh 4
• PowerHA 7.1 Enterprise Edition (5770-HAS) – bei Verwendung von LUN Level Swithing ist die Standard Edition ausreichend
• PTF SI44148 und SI45741 für 5770-HAS (Achtung – spezielle Instruktionsanweisungen beachten)
• IBM i 7.1 mit Technology Refresh 6 und PTF SI48371 für 5770-HAS bei Einsatz von LUN Level Switching
• Anschluß von V7000 oder SVC über NPIV (nicht vSCSI) bei Einsatz von LUN Level Switching
• Mindestens VIOS 2.2.1
• Mindestens SVC / V7000 6.1