In diesem Dokument werden Best Practices für eine homogene Db2-Migration zu Compute Engine beschrieben. Es richtet sich an Datenbank- und Systemadministratoren sowie an Software Engineers, Database Engineers und Operations Engineers, die Db2-Umgebungen zu Google Cloud migrieren. Migrationen von Db2 zu anderen Datenbanktypen werden in diesem Dokument nicht behandelt.
Begriffserläuterung
- IBM Db2
- Ein relationales Datenbankverwaltungssystem (Relational Database Management System, RDBMS) mit Replikations- und Failover-Funktionen für Unternehmen.
- Notfallwiederherstellung für Hochverfügbarkeit (High Availability Disaster Recovery, HADR)
- Eine Funktion für Db2, die protokollierte Datenbankaktivitäten verwendet, um Daten aus der Primärdatenbank in die Standby-Datenbank zu replizieren. Dieses Feature ermöglicht einen manuellen Failover von der primären Datenbank zur Standby-Datenbank.
- Primäre Maschine
- Die Maschine, auf der Db2 gehostet wird und die sowohl Schreib- als auch Leseanfragen akzeptiert. Die Replikation auf die Standby-Maschine stammt von dieser Maschine.
- Haupt-Standby
- Eine Standby-Maschine, die nur Leseanfragen annehmen kann. Diese Maschine unterstützt alle von Db2 zugelassenen Synchronisationsmodi und ist als Failback-Instanz für HADR-Zwecke vorgesehen. IBM Db2 lässt eine einzige Maschine dieser Art pro Cluster zu.
- Hilfs-Standby
- Eine Standby-Maschine, die nur Leseanfragen annehmen kann. Diese Maschine unterstützt nur den Synchronisationsmodus SUPERASYNC und befindet sich in einem anderen Rechenzentrum als die primäre Maschine, für den Fall eines manuellen Failovers bei einem Ausfall des Hauptrechenzentrums.
- Tivoli System Automation for Multiplatforms (TSA/MP)
- Eine Software für die Clusterverwaltung, die den automatischen Ressourcen-Failover von der primären Datenbank zur Haupt-Standby-Datenbank ermöglicht. Diese Software enthält Netzwerk-, Speicher- und Rechenressourcen, die als Teil des Clusters definiert sind. Die Db2 Enterprise Edition umfasst die TSAMP-Berechtigung für HADR.
- Automatic Client Reroute (ACR)
- Ein Db2-Feature, das Clientanwendungen von einem ausgefallenen Server auf einen anderen Server umleitet, sodass die Anwendungen mit minimaler Unterbrechung weiterarbeiten können.
- Change Data Capture (CDC)
- Eine Reihe von Verfahren oder Tools zum Erkennen von Änderungen in einer Datenbank, z. B. das Synchronisieren von Daten mit einer anderen Datenbank oder das Erstellen eines Audit-Trails.
Architektur
Ein Db2-Cluster besteht in der Regel aus dem Primärknoten und dem Haupt-Standby-Knoten, die über HADR verbunden sind. In neueren Versionen von Db2 können Sie auch Hilfs-Standby-Knoten zur Notfallwiederherstellung hinzufügen.
Im folgenden Diagramm ist eine Quellumgebung abgebildet:
In dieser Umgebung befinden sich die primäre Maschine und die Haupt-Standby-Maschine in einem Rechenzentrum und die Hilfs-Standby-Maschinen in anderen Rechenzentren.
Ein Migrationsziel besteht darin, diese Umgebung in Google Cloud neu zu erstellen, wie im folgenden Diagramm dargestellt:
In der folgenden Tabelle werden Aspekte der einzelnen Migrationstypen miteinander verglichen:
| Migrate to Virtual Machines | Q Replication | SQL Replication | HADR | |
|---|---|---|---|---|
| Quellen | VMware, AWS-VMs (Amazon Web Services) | Beliebige Db2-Umgebung, anhand von Lizenzierung | Beliebige Db2-Umgebung | Beliebige Db2-Umgebung |
| Was wird repliziert? | Replikation von Laufwerken auf Blockebene | Tabellen in der Datenbank | Tabellen in der Datenbank | Gesamte Datenbank |
| Umstellung | Es dauert einige Minuten, bis eine VM in Google Cloud gestartet wird | Anwendungen und DNS auf die Compute Engine-Instanzen verweisen | Anwendungen und DNS auf die Cloudinstanzen verweisen | Anwendungen und DNS auf die Cloudinstanzen verweisen |
| DDL-Änderungsreplikation | Ja (Schreibvorgänge werden repliziert) | Ja | Ja | Ja |
| Synchrone Datenreplikation | – | Nein | Ja | Ja |
| Asynchrone Datenreplikation | – | Ja | Ja | Ja |
| Datenreplikation zu einem bestimmten Zeitpunkt | Nein | Ja | Ja | Nein |
Anhand der vorhergehenden Tabelle können Sie Ihre Anforderungen mit der jeweiligen Systemverfügbarkeit abgleichen und mit dem Ressourcenaufwand, der jeweils nötig ist, um das Zielsystem und die Replikation einzurichten sowie die Replikation über einen längeren Zeitraum zu warten und zu testen. Die Tabelle zeigt, dass Migrate to VMs der am einfachsten zu implementierende Ansatz ist, aber der am wenigsten flexible in Bezug auf die Systemverfügbarkeit. HADR, Q Replication und SQL Replication haben geringere Auswirkungen auf die Systemverfügbarkeit, erfordern aber jeweils mehr Aufwand, um die Replikation in einem parallelen Modell einzurichten und zu verwalten.
Migrationstypen
Es gibt zwei Möglichkeiten, Db2 zu Compute Engine zu migrieren:
- Migrationen, bei denen eine vorhandene Clusterkonfiguration oder -topologie geändert wird
- Migrationen, die Daten in völlig neue Cluster replizieren.
Beim Ändern eines bereits bestehenden Clusters muss kein neuer Cluster in der Cloud gestartet werden, was möglicherweise Zeit spart. Beim anderen Migrationstyp müssen Sie einen neuen Cluster in Google Cloud bereitstellen. Dies hat dafür geringere Auswirkungen auf den vorhandenen Cluster, da die Replikation out-of-band erfolgt. Diese Methode ist auch praktisch, wenn Sie nur einen Teil der Datenbank replizieren oder Transformationen an den Daten vornehmen möchten, bevor sie in der Zieldatenbank landen.
In den folgenden Abschnitten wird erläutert, was zu beachten ist, bevor Sie Db2-Instanzen in Google Cloud verschieben. Möglicherweise funktionieren einige häufig verwendete Funktionen in Google Cloud nicht unverändert oder erfordern einige Konfigurationsänderungen.
Floating-IP-Adressen (virtuelle IP-Adressen)
In einem hochverfügbaren Db2-Cluster kann TSA/MP dem primären Knoten eine virtuelle IP-Adresse zuweisen. Diese Adresse wird auch als Floating-IP-Adresse bezeichnet. Bei einer Floating-IP-Adresse wird der Traffic immer zum primären Knoten und nicht zum Standby-Knoten geleitet.
Compute Engine verwendet einen virtualisierten Netzwerk-Stack in einem VPC-Netzwerk (Virtual Private Cloud), sodass typische Implementierungsmechanismen möglicherweise nicht angewandt werden können. Beispielsweise verarbeitet das VPC-Netzwerk ARP-Anfragen (Address Resolution Protocol) anhand der konfigurierten Routingtopologie und ignoriert Gratuitous-ARP-Frames. Darüber hinaus ist es nicht möglich, die Routingtabelle des VPC-Netzwerks direkt mit Standard-Routingprotokollen wie Open Shortest Path First Protocol (OSPF) oder Border Gateway Protocol (BGP) zu ändern. Daher müssen Sie entweder eine Alternative zu Floating-IP-Adressen implementieren oder ACR verwenden.
Wenn Sie einige oder alle Knoten in einem Db2-Cluster verschieben, müssen Sie die Floating-IP-Adressen für Ihren Cluster deaktivieren, bevor Sie die Knoten verschieben.
ACR
Wenn Ihre Db2-Umgebung ACR verwendet, müssen Sie möglicherweise den Katalog Ihrer Clients ändern, wenn sich die DNS-Namen ändern oder wenn Ihre Clients eine Verbindung mithilfe von IP-Adressen herstellen.
Tiebreaker
Bei TSA/MP wird vorausgesetzt, dass die Mehrheit der Clusterknoten online ist, damit Automatisierungsaktionen gestartet werden können. Wenn der Cluster eine gerade Anzahl von Knoten enthält, besteht die Möglichkeit, dass genau die Hälfte der Knoten des Clusters online ist, und es besteht die Möglichkeit einer Split-Brain-Situation. In diesem Fall verwendet TSA/MP einen Tiebreaker, um den Quorumstatus (Mehrheitsgruppenstatus) festzulegen, der bestimmt, ob Automatisierungsaktionen gestartet werden können.
Ihre Db2-Umgebung kann die folgenden Tiebreaker verwenden:
- Speicher- oder Laufwerk-Tiebreaker: IBM Db2 verwendet Laufwerkreservierungen für den Tiebreaker. Da Reservierungen für Google Cloud nicht verfügbar sind, müssen Sie einen anderen Typ von Tiebreaker auswählen.
- Netzwerk-Tiebreaker: Verwendet eine externe IP-Adresse (des Clusters) für den Tiebreaker. In einer Hybridbereitstellung muss Ihr Netzwerk-Tiebreaker nicht unbedingt sofort in Google Cloud verschoben werden, solange er von den Clusterknoten aus erreichbar ist. Nach der Ausführung Ihres Clusters in Google Cloud empfiehlt es sich jedoch, den Tiebreaker in einer anderen Zone zu erstellen oder den Google Cloud-Metadatenserver als Tiebreaker zu verwenden.
- NFS-Tiebreaker: Der NFS-Tiebreaker wird in Situationen eingesetzt, in denen Reservedateien auf einem NFS v4-Server gespeichert sind. Wie beim Netzwerk-Tiebreaker können auch der NFS-Tiebreaker und der NFS v4-Server in einer Hybridbereitstellung am ursprünglichen Standort verbleiben. Später empfiehlt es sich, einen eigenen NFS-Server bereitzustellen oder Partnerprodukte wie Elastifile als NFS-Tiebreaker-Ziele in Google Cloud zu verwenden.
Mit Migrate to VMs migrieren
Wenn beide folgenden Bedingungen für Ihre Umgebung zutreffen, wird Migrate to VMs empfohlen:
Sie haben eine VMware vCenter-Umgebung oder virtuelle Maschinen in Amazon Elastic Compute Cloud (Amazon EC2).
Sie haben eine private Verbindung von Google Cloud zu Ihrer Umgebung, z. B. Cloud VPN oder Cloud Interconnect.
Mit Migrate to VMs migrieren Sie virtuelle Maschinen von lokalen und Cloud-Umgebungen zu Google Cloud. Sie können eine virtuelle Maschine in wenigen Minuten auf Google Cloud migrieren, während die Daten im Hintergrund kopiert werden, die virtuellen Maschinen jedoch vollständig betriebsbereit sind. Sie müssen eine private Verbindung zwischen Ihrer Quellumgebung und Ihrem Google Cloud-Projekt haben, z. B. Cloud VPN, Cloud Interconnect oder Partner Interconnect.
Mit Migrate to VMs müssen Sie die Datenbankkonfiguration auf den Cloud-VMs neu evaluieren. Einige Konfigurationen sind möglicherweise nicht für Google Cloud optimiert, z. B. Registry-Variablen, Zwischenspeicherpools, Datenbankmanager-Konfigurationen oder Datenbankkonfigurationen.
Über das Dienstprogramm AUTOCONFIGURE können Sie mit einer Referenzversion beginnen.
Die Betriebsmethode „Migrate to VMs“ wird im VM-Migrationslebenszyklus detailliert beschrieben.
In den folgenden Abschnitten wird dargestellt, wie diese Methode auf eine Db2-Umgebung angewendet wird.
Testklone
Testklone sind nur in vCenter-Umgebungen verfügbar.
Migrate to VMs kann einen Snapshot Ihrer VM erstellen und damit eine sofort einsatzbereite Compute-Instanz in Google Cloud erstellen. Sie können die Db2-Umgebung in Google Cloud neu erstellen, Konfigurationsänderungen ausprobieren und die Bereitstellung ohne Auswirkungen auf die Quellumgebung testen sowie ihre Leistung ermitteln.
Das folgende Diagramm zeigt die DB2-Umgebung in Google Cloud mit der parallelen Umgebung in Google Cloud nach einem Testklonvorgang mit Migrate to VMs.
Nachdem Sie die Leistung der Testklone in Google Cloud ermittelt und sie getestet haben, können sie gelöscht werden.
Run-in-Cloud
Beim Aktivieren von Run-in-Cloud fährt Migrate to VMs den Quellcluster herunter und startet die VMs in Google Cloud. Dabei werden nur die erforderlichen Daten abgerufen und nicht der gesamte Speicher zu Google Cloud gestreamt. Run-in-Cloud unterstützt das Zurückschreiben und ist standardmäßig aktiviert. Durch Migrate to VMs können Sie Ihre Umgebung testen, bevor Sie den Speicher aktiv streamen. Sie können die VM auch mithilfe des Move-Back-Features zurück in Ihre Quellumgebung verschieben. Bei Cloud-zu-Cloud-Migrationen können Sie keine Schreibvorgänge zurück in die Quelle replizieren.
Im folgenden Diagramm ist die Run-in-Cloud-Phase dargestellt, wobei alle Knoten in der Cloud ausgeführt werden. Sie können Clusterknoten nach und nach statt alle auf einmal verschieben.
Migration
Die Migrationsphase ähnelt der Run-in-Cloud-Phase. Aber Migrate to VMs streamt den Speicher auch aktiv zu Google Cloud. Während der Run-in-Cloud-Phase liefert Migrate to VMs nur bei Bedarf Daten, um Bandbreite zu sparen, da Sie noch nicht angegeben haben, dass Sie bereit sind, die VM vollständig zu verschieben.
Trennen
In dieser Phase synchronisiert Migrate to VMs die Daten aus dem Cache und dem Objektspeicher mit den nativen Datenlaufwerken in Google Cloud und fügt die Laufwerke dann der VM hinzu. In dieser Phase müssen Sie die VM in Google Cloud herunterfahren. Für Db2 empfiehlt es sich, jeweils nur einen Knoten vom Cluster zu trennen.
Replikation verwenden
Bei der Replikation von Db2 werden Änderungen aus dem Transaktionslog mit einer Capture-Anwendung erfasst und dann mit einer Apply-Anwendung auf einen anderen Cluster angewendet. Die Art und Weise, in der die Capture-Anwendung die Änderungen erfasst, und der Kommunikationskanal, der zum Übertragen der Änderungen an die Apply-Anwendung verwendet wird, unterscheiden sich zwischen den Replikationstypen.
Im folgenden Diagramm ist der logische Informationsfluss der Db2-Replikation dargestellt.
Die Capture-Anwendung erfasst Änderungen in der Datenbank und sendet sie an die Apply-Anwendung. Die Apply-Anwendung schreibt diese Änderungen in die Zieldatenbank. Es gibt einige Transformationen, die die Anwendungen mit den Daten selbst durchführen können. Die Capture- und die Apply-Anwendung müssen nicht unbedingt auf dem Datenbankserver ausgeführt werden.
SQL Replication
Bei SQL Replication werden Änderungen an Quelltabellen und Quellansichten erfasst und Staging-Tabellen zum Speichern von Transaktionsdaten verwendet, für die ein Commit durchgeführt wurde. Die Änderungen werden dann aus den Staging-Tabellen gelesen und in entsprechende Zieltabellen repliziert. Zum Zeitpunkt der Erstellung dieses Dokuments steht Ihnen bei der Installation von Db2 SQL Replication zur Verfügung.
So sieht ein Migrationsprozess mit SQL Replication aus:
- Stellen Sie Db2 in Google Cloud bereit.
- Konfigurieren Sie SQL Replication.
- Starten Sie SQL Replication.
- Prüfen Sie, ob die Bereitstellungen synchron sind.
- Lassen Sie die Anwendungen auf die Google Cloud-Instanz verweisen. Beenden Sie die Replikation.
Im folgenden Diagramm ist ein Beispiel mit SQL Replication dargestellt.
Ihre Produktionsumgebung funktioniert wie gewohnt und repliziert die SQL-Befehle in den neuen Cluster, den Sie in Google Cloud erstellen. Im Diagramm wird der Replikationsprozess auf der primären Instanz ausgeführt. Es gibt jedoch verschiedene Bereitstellungsmöglichkeiten, die in diesem Dokument nicht erläutert werden.
Q Replication
Q Replication ist eine aktuellere und effizientere Methode als SQL Replication, mit der Daten von einer Db2-Instanz in eine andere repliziert werden. Diese Methode verwendet IBM MQ, um Datenänderungseinträge bereitzustellen. Dies bedeutet, dass Sie eine Instanz von IBM MQ in der Quellumgebung und eine in der Zielumgebung erstellen müssen. Diese Replikationsmethode ist schneller als SQL Replication, da sie im Speicher abläuft. SQL Replication ist zwar langsamer, allerdings ist Q Replikation in der Regel schwieriger einzurichten, da Sie IBM MQ einrichten müssen. Je nachdem, welche Db2-Lizenz Sie haben, müssen Sie möglicherweise eine zusätzliche Lizenz für Q Replication erwerben.
Wenn Sie Q Replication für Db2 starten, können Sie zwischen den folgenden beiden Methoden wählen:
Automatisches Laden: Die Prozesse von Q Replication führen den anfänglichen Ladevorgang aus. Dies bedeutet, dass die Zieldatenbank aus einer Sicherung der Quelle wiederhergestellt wird.
Manuelles Laden: Sie führen selbst den anfänglichen Ladevorgang aus und starten dann die Replikation ab diesem Punkt im Log.
So sieht ein Migrationsprozess aus:
- Stellen Sie IBM MQ in Google Cloud und in Ihrer Quellumgebung bereit.
- Stellen Sie Db2 in Google Cloud bereit.
- Konfigurieren Sie Q Replication.
- Starten Sie Q Replication (entweder mit manuellem oder automatischem Laden).
- Prüfen Sie, ob die beiden Bereitstellungen synchron sind.
- Lassen Sie die Anwendungen auf die Google Cloud-Instanz verweisen. Beenden Sie die Replikation.
Im folgenden Diagramm ist eine mögliche Lösung mit Q Replication dargestellt.
Die Quellumgebung verwendet Q Replication von IBM, um die Datenbankänderungen an IBM MQ und die Zielumgebung zu senden, wodurch ein Db2-Cluster auf Compute Engine erweitert wird.
Bei diesem Ansatz werden die bestehenden Db2-Cluster nach und nach zu Compute Engine verschoben, wobei HADR für die Datenübertragung zwischen Knoten sorgt.
Dieser Ansatz wird empfohlen, wenn die folgenden Bedingungen erfüllt sind:
- Sie möchten keinen neuen Cluster in Compute Engine bereitstellen.
- Sie können Migrate to VMs nicht nutzen.
- Sie können keine der Replikationsoptionen verwenden.
- Sie können kein Partnerprodukt verwenden (z. B. aufgrund von Lizenzierung, Kosten oder Compliance).
Wenn Ihre Db2-Version eine Hilfs-Standby-Instanz nicht unterstützt
In diesem Fall können Sie folgende Aktionen ausführen:
- Stellen Sie eine Db2-Instanz auf Compute Engine bereit.
- Erstellen Sie eine Sicherung Ihrer Primärinstanz.
- Stellen Sie die Db2-Instanz in Compute Engine aus der Sicherung wieder her.
- Entfernen Sie die Standby-Instanz aus der HADR-Einrichtung.
- Hängen Sie die Db2-Instanz in Compute Engine als Standby an. Sie können den gewünschten Synchronisierungsmodus auswählen, aufgrund der möglicherweise höheren Latenz könnten
ASYNCundNEARASYNCjedoch besser geeignet sein. - Führen Sie einen Failover zur Compute Engine-Db2-Instanz durch und machen Sie sie zur primären HADR-Instanz.
- Erstellen Sie eine weitere Compute Engine-Db2-Instanz, stellen Sie sie aus der Sicherung wieder her und richten Sie sie als HADR-Standby-Instanz ein.
Der erste Schritt im folgenden Diagramm zeigt die neu erstellte Db2-Instanz in Google Cloud, die als Haupt-Standby der primären Db2-Quelldatenbank eingerichtet wurde.
Im vorhergehenden Diagramm wird die Google Cloud-Instanz zur primären HADR-Instanz. Entfernen Sie anschließend die Haupt-Standby-Instanz der Quelle und hängen Sie eine weitere Db2-Instanz in Compute Engine als Haupt-Standby-Instanz an.
Wenn Ihre Db2-Version eine Hilfs-Standby-Instanz unterstützt
Eine Möglichkeit besteht darin, die gleichen Schritte wie oben auszuführen, wo die Db2-Version keine Hilfs-Standby-Instanz unterstützt, und am Ende auch die Hilfs-Standby-Instanzen zu verschieben.
Eine weitere Möglichkeit ist, die Hilfsreplikate für einen Wechsel zu Google Cloud zu nutzen. Dies ist fehlertoleranter, da Sie nicht die Primärinstanz oder die Haupt-Standby-Instanz in der Quellumgebung und das jeweilige Gegenstück in Google Cloud haben. In der folgenden Liste sind die Schritte für diese zweite Option aufgeführt:
- Stellen Sie die Db2-Instanzen (Primär-, Haupt-Standby- und ggf. Hilfs-Standby-Instanzen) in Compute Engine an ihrem jeweiligen Standort bereit.
- Entfernen Sie die Hilfs-Standby-Knoten aus dem Quellcluster.
- Konfigurieren Sie die Knoten, die als Primärknoten und Haupt-Standby-Knoten für die Hilfs-Standby-Knoten des Quellclusters fungieren werden.
- Führen Sie eine Übernahme mit einer der Compute Engine-Instanzen durch. Diese Instanz wird zur primären Instanz. Konfigurieren Sie eine der anderen Compute Engine-Instanzen als Haupt-Standby-Instanz der primären Instanz.
Der erste im folgenden Diagramm dargestellte Schritt zeigt zwei der neu erstellten Db2-Instanzen in Compute Engine.
Die Instanzen werden als Hilfs-Standby-Instanzen der primären Db2-Instanz der Quellumgebung eingerichtet, um die Hilfs-Standby-Instanzen der Quellumgebung zu ersetzen. Nach der Übernahme einer Compute Engine-Instanz wird diese Instanz zur primären HADR-Instanz. Eine weitere Instanz wird als Haupt-Standby-Instanz konfiguriert. Im letzten Schritt werden zwei weitere Instanzen als Hilfs-Standby-Instanzen konfiguriert.
Partnerprodukte
Google hat mehrere Partner, die Produkte für eine solche Migration anbieten. Die meisten dieser Produkte nutzen CDC, um Daten zwischen der Quell-Db2-Instanz und der Zielinstanz zu replizieren. Diese Produkte sind keine Google Cloud-Produkte. Sie müssen sich also zur Lizenzierung und zu den Preisen für jedes Produkt oder jeden Dienst zusätzlich informieren. Normalerweise repliziert dieser Dienst Daten aus einem vorhandenen Cluster in einen anderen Cluster, den Sie in Google Cloud erstellen. Der allgemeine Ansatz ähnelt den in diesem Dokument beschriebenen Replikationsszenarien.
Hier einige Partnerprodukte:
Nächste Schritte
- IBM Db2 für SAP – Planungsanleitung
- Migration von Datenbanken zu Google Cloud
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center