von Michael Weber

Technologieübersicht

Der Ausgangspunkt für Db2® Mirror ist ­POWER8™, POWER9™ oder neuere Power Technologie. Db2® Mirror benötigt zwei IBM® i LPARs, die über „RDMA (Remote Direct Memory Access) over Converged Ethernetkarte“ oder RoCE (RDMA over Converged Ethernet)-Netzwerkprotokoll und die zugehörige Hardware miteinander verbunden sind. Externer Storage mit Kopiertechnologie ist ebenfalls erforderlich. Bei Verwendung von IBM®-Storage wird beim ­Einrichten von Db2® Mirror die Installation und Integration bereit­gestellt.

Die Mindestanforderung des Firmware-Level ist für POWER8®-Server FW860.60 und für POWER9™ FW930.

Die folgende Abbildung (Abb. 1.: Grundlagen von Db®2 Mirror) zeigt zwei LPARs mit jeweils eigener Datenbank, die Db2® Mirror Knoten (Node) genannt werden. Da Datenänderungsanforderungen auf beiden Knoten auftreten, verwendet Db2® Mirror automatisch die synchrone Replikation, um die beiden Instanzen identisch zu halten.

Wenn einer der Knoten nicht verfügbar ist, verfolgt Db2® Mirror jede Änderung der replizierten Objekte auf dem aktiven Knoten.

Sobald das gespiegelte Paar wieder verbunden ist, werden alle Änderungen zwischen den Knoten synchronisiert, so dass nach der Re-synchronisierung beide Datenbanken wieder identisch sind. Db2® Mirror unterstützt Bibliotheken und Objekte, die sich entweder in SYSBAS oder einem IASP (Independant ­Auxiliary Storage Pool) befinden.

Db2® Mirror Vorteile

Db2® Mirror ist einfach zu implementieren und einzusetzen. Synchrone Replikation hält beide Knoten identisch.

Produktionsdaten können auf beiden Knoten genutzt werden. Die Anwendung wird auf einem der Knoten ausgeführt, wobei der andere im aktiven Standby­-Modus einsatzbereit ist. Diese Funktion wird als aktiv/passiv Umgebung bezeichnet.

Bei Echtzeit-Analysen der Daten bietet Db2® ­Mirror die Möglichkeit, eine Kopie der Produktionsdaten auf dem zweiten Knoten zu erzeugen. Es ist dann möglich die Produktionsumgebung auf einem der Knoten auszuführen, während die Abfragen und Business ­Intelligence-Aufgaben auf dem zweiten Knoten ohne Leistungsverlust erzeugt werden können.

Zu „Load Balancing“ Zwecken können Benutzer und Anwendungen auf die Knoten verteilt werden. Dies wird als aktive/aktive Umgebung bezeichnet. Da die Updates der replizierten Daten synchron sind, sehen die Benutzer auf beiden Knoten immer die gleichen Daten. Mit Hilfe des Betriebssystems kann ein „­Locking“ über die Knoten hinweg implementiert werden.

Dies stellt die Integrität von Änderungen sicher.

Falls einer der Knoten nicht mehr verfügbar ist, können Benutzer und Anwendungen auf den aktiven Knoten umgeleitet werden. Dies reduziert Ausfallzeiten in diesen Umgebungen.

Geplante System- oder Anwendungswartung, innerhalb einer Produktionsumgebung, können zu einem Ausfall führen.

Db2® Mirror kann Produktionsausfälle aufgrund ­geplanter IPLs (Initial Program Load) und ­­ Updates ­ reduzieren und in einigen Fällen sogar eliminieren. Mit der Möglichkeit, die Replikation vorübergehend auszusetzen, kann ein Knoten die Verarbeitung von Transaktionen fortsetzen, während der andere Knoten IPLed oder dort die Wartung durchgeführt wird.

Sobald der IPL abgeschlossen ist und die Kommunikation zwischen den Knoten wiederhergestellt wurde, werden die Änderungen aktualisiert und auf den zweiten Knoten verschoben.

Nun kann der IPL oder die Wartung auf dem ersten Knoten erfolgen.

Planungsüberlegungen

Software-Anforderungen

Db2® Mirror erfordert IBM® i 7.4 oder höher. Bevor man mit dem Setup-Prozess der Db2®-Mirror- Umgebung beginnen kann, müssen die neuesten PTF-Gruppen auf dem Setup Quellenknoten installiert werden.

• IBM® i Kumulatives PTF-Paket
• Db2® Mirror PTF Group
• Db2® für IBM i PTF Group

Der Managing-Knoten sollte die folgenden PTF-Gruppen haben:

• Db2® Mirror PTF Group
• IBM® HTTP Server for i PTF Group
• Java™ PTF Group

Ein neues Lizenzprogramm (LPP) IBM Db2® Mirror for i (5770-DBM) und die IBM ® i Option 48 (Db2®Data Mirroring) sind weitere Softwarevoraussetzungen. Db2® Data Mirroring wird mit der Bestellung von 5770-DBM automatisch mitgeliefert.

Der Setup-Quell-Knoten und der Verwaltungsknoten müssen die auf der folgenden Webseite angegebenen Optionen und Produkte installiert haben.
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_74/db2mi/db2mplanningsoftware.htmardareH

Weitere Hardware-Anforderungen

Netzwerkadapter

Db2® Mirror erfordert ein schnelles Netzwerk mit geringer Latenz und hoher Bandbreite zwischen den Knoten. Um dies zu erreichen, wird Remote Direct Memory Access (RDMA) über Converged Ethernet (RoCE)-Netzwerktechnologie verwendet.

Adapter, die RoCE unterstützen, müssen in beiden Partitionen installiert sein. Die Adapter können direkt miteinander verkabelt oder optional über einen Switch angeschlossen werden. Der maximale physikalische Abstand zwischen den beiden Knoten wird durch die Länge der Kabel begrenzt. Zurzeit beträgt der Abstand maximal 100 m, um die geringen Latenzen für die Synchronität der Daten zu erzielen. Es werden 100 Gb Netzwerkkarten empfohlen .

HMC:

Die Db2® Mirror-Knoten müssen von einer HMC (Hardware Management Console) verwaltet werden.

Die IBM® i-Partition, die als Setup-Copy-Knoten für den Klonvorgang verwendet wird, muss erstellt und definiert werden, bevor der Db2® Mirror-Konfigurationsprozess gestartet wird.

Diese Partition kann auf derselben HMC oder auf einer anderen HMC definiert werden. Der HMC REST-Dienst muss ausgeführt werden und den Standard Port 12443 verwenden.

Die Firmware-Mindestanforderung der HMC ist für POWER8® V8R8.6.0 und für POWER9™ V9R1.930.0.

Externer Storage:

Die Db2® Mirror-Umgebung erfordert externen Speicher. IBM® System Storage® DS8000® oder IBM Spectrum® Virtualize wird empfohlen, ist jedoch nicht Voraussetzung.

IBM® System Storage® DS8000® oder IBM® Spectrum® Virtualize wird empfohlen, da die Klonvorgänge während der Db2® Mirror-Einrichtung vollständig automatisiert sind. Externe Speichersysteme von Drittanbietern oder andere IBM®-Speichersysteme können verwendet werden. Die Storage-Cloning­-Operationen müssen während des Setup-Prozesses dann manuell ausgeführt werden.

Host- und Volume-Planung

Bevor mit der Konfiguration von Db2® Mirror ­begonnen werden kann, muss der Storage-Host definiert und die Volumes für den Setup-Copy-Knoten zugewiesen sein.
Die Anzahl der Storage-Hosts, die Volumes und die Volumegrössen müssen für den Setup-Quell-Knoten und den Setup-Copy-Knoten gleich sein.
Der Db2® Mirror Storage Cloning Prozess koppelt Volumes zwischen der Setup-Quelle (Knoten) und dem Setup-Copy-Knoten. Es können nur Datenträger mit gleicher Größe und gleichem Typ gepaart werden.

Die Abbildung 2 zeigt eine SYSBAS-Speicher­konfiguration.

Datenbank: Independent Auxiliary Storage Pools (IASPs)

Die Abbildung 3 zeigt eine IASP-Speicherkonfiguration.

Der Storage-Host und die Volumes für alle ­Datenbank-IASPs müssen für den Setup-Copy-Knoten ­vordefiniert sein. Erst dann ist es möglich den IASP zu Db2® Mirror hinzuzufügen.

Cloning-Methoden

Es gibt mehrere Möglichkeiten, den Setup-Quell-Knoten zu klonen, um den Knoten für die Setup-Kopie zu erstellen.

Die folgenden Storagekopierverfahren werden unterstützt:

FlashCopy® – wird verwendet, wenn sich der ­Storage für beide Knoten auf demselben IBM®-Storage Server befindet.

Remote-Copy – wird verwendet, wenn sich der Storage für jeden Knoten auf separaten IBM®-Storage Servern befindet. Es werden Global Copy-Funktionen zum Erstellen des Setup-Copy-Knoten genutzt.

Manual-Copy – Das Klonen von ­Storage ­erfolgt ohne die Hilfe des automatisierten ­Assistenten. Diese Option muss für externen
Drittanbieterspeicher und für IBM®-Storage verwendet werden.

Das Klonen kann entweder mit einem „Cold“- oder „Warm“-Klon durchgeführt werden:

Cold Cloning – Der Setup-Quell-Knoten wird während des Prozesses abgeschaltet. Dies gewährleistet eine möglichst genaue Kopie aller Daten auf dem Quell-Knoten, da während der Kopie keine Änderungen vorgenommen werden können.

Warm Cloning Der Setup-Quell-Knoten wird während des Prozesses nicht abgeschaltet. Dadurch können während des Klonens Änderungen am Quell-Knoten vorgenommen werden. Die Änderungen an den replizierten Objekten werden von Db2® Mirror verfolgt. Nach Abschluss werden die Änderungen synchronisiert, um die Konsistenz der Objekte zwischen den Knoten zu gewährleisten.

 

 

 

Der Db2® Mirror-Klonprozess unterstützt nur Standard-Volumes für IBM® System Storage® DS8000®. Die Volumes können nicht „Space-Efficient“ oder „Thin-Provisioned“ definiert werden.

Für IBM® Spectrum® Virtualize können sie „Thin-Provisioned“ angelegt werden.

Native oder Virtual I/O Server (VIOS) – Anbindung

Die Anbindung von IBM® System Storage® DS8000® oder IBM® Spectrum Virtualize® erfordert einen Fibre Channel-Adapter mit „Native“ – ­Anbindung oder eine Anbindung durch VIOS N_Port ID ­Virtualization (NPIV).

User Interface

Beim Einrichten, Verwalten und Überwachen der Db2® Mirror-Umgebung können zwei Schnittstellen verwendet werden: IBM® Db2®Mirror for i Graphical User Interface (GUI) und SQL-Dienste, die aus SQL-Prozeduren, SQL-Funktionen und -Ansichten bestehen.
Die Db2® Mirror GUI-Schnittstelle ist eine web­basierte Schnittstelle, die auf IBM® i ausgeführt wird. Sie kann auf einem der beiden Db2® Mirror-Knoten oder auf einem separaten, dritten IBM® i-Knoten installiert werden. Die GUI wird zusammen mit der Basis von Db2® Mirror for i (5770-DBM), ausgeliefert.

Das Tool stellt die notwendigen Schnittstellen bereit, um alle Aspekte der Db2® Mirror-Umgebung einzurichten und zu verwalten. (Abb. 4: Db2® Mirror ­Graphical User Interface).

SQL Services

Als programmgesteuerte Alternative zur GUI stehen SQL-Dienste zur Steuerung und Überwachung von Db2® Mirror zu Verfügung. Es werden keine IBM® i CL-Befehle oder APIs bereitgestellt. Die verfügbaren Dienste findet man im IBM i® Access ­Client ­Solutions-Tool ab Version 1.1.8.2 (ACS) unter Run SQl Script / Insert from Example / Db2® Mirror
(Abb. 5: ACS – Db2® Mirror)

Rechenzentrumsarchitektur (Beispiele)

Aufgrund des synchronen Designs von Db2® Mirror ist die Entfernung zwischen den Knoten auf ein Rechenzentrum beschränkt. Es werden mehrere Konfigurationen unterstützt, sowohl für eine Db2® Mirror-Implementierung im Rechenzentrum als auch für das Hinzufügen einer Disaster Recovery (DR) – Lösung.

Db2® Mirror-Umgebung mit einem Storage-Server

 

Basisumgebung mit zwei Storage-Servern

Die Verwendung mehrerer Storage-Server bietet zusätzliche Redundanz, indem sichergestellt wird, dass der aktive Knoten während eines Ausfalls ausgeführt und verfügbar bleibt. Bei zwei Storage-Servern wird Remote-Copy-Technologie anstelle von FlashCopy® verwendet. Mehrere HMCs bieten eine zusätzliche Redundanzebene und werden vollständig vom Db2® Mirror-Setup-Prozess unterstützt. (Abb. 7: Basiskonfiguration mit zwei Storage-Servern)

Db2® Mirror und Disaster Recovery – Überlegungen

Db2® Mirror ist eine Verfügbarkeitslösung, sie ist aber nicht als Disaster Recovery (DR) Lösung zu betrachten. Db2® Mirror kann aber bei einer DR-Situation die Verfügbarkeit der gesamten Umgebung erheblich verbessern. (Abb. 8: Beispiel Db2® Mirror – Konfiguration mit Disaster Recovery)

Db2® Mirror in Kombination mit IBM® PowerHA SystemMirror for i (5770-HAS) ist eine Option für lokale Verfügbarkeit und Disaster Recovery. Die PowerHA-Replikation basiert auf der IASP-Technologie, die auch in Db2® Mirror unterstützt wird. (Abb. 9: Db2® Mirror und PowerHA)

Detailinformationen findet man auf folgenden IBM ®-Webseiten

IBM® Db2® Mirror for i YouTube

IBM®Knowledge Center Db2® Mirror

https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_74/db2mi/db2mintro.htm

IBM® i Version 7.4 – Availability Db2® Mirror

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/db2mi/db2mipdf.pdf?view=kc

 

Über den Autor:

Der Autor Michael Weber ist Senior IT Spezialist für Power Systeme bei der IBM® Deutschland GmbH und per Email erreichbar unter: mweber (ät) de.ibm.com.