Migrieren von Datenbanken nach Google Cloud VMware Engine (GCVE)

Dieser Beitrag behandelt einige Prozesse und Tools, die häufig für die Migration lokaler Datenbanken, oft auf VMware, nach Google Cloud VMware (GCVE) verwendet werden. Viele Kunden wählen diesen Lift-and-Shift-Ansatz als ersten Schritt, um Datenbanken rasch nach Google Cloud zu migrieren, bevor sie mit der Aktualisierung und Modernisierung der Datenbank beginnen.

Google Cloud VMware Engine

GCVE ist ein vollständig managed Service, mit dem Sie eine VMware-Umgebung in Google Cloud betreiben können. Die Lösung umfasst vSphere, vCenter, vSAN, NSX-T und die entsprechenden Tools. GCVE ermöglicht den Betrieb von VMware-Umgebungen  an einer Vielzahl von Google Cloud-Standorten nativ auf dedizierter Google Cloud Bare Metal-Infrastruktur. GCVE stellt alle Funktionen bereit, die für eine effiziente und sichere Nutzung von VMware benötigt werden. Jeder Cluster besteht aus mindestens drei Nodes und sorgt mit vSphere High Availability für Hochverfügbarkeit der betriebenen VMs. Weitere Informationen zu vSphere HA finden Sie unter folgendem Link:  Arbeitsweise von vSphere HA.

Zu beachten ist:

• Eine GCVE Private Cloud = 1 vCenter + 1 NSX-T Manager + 1 HCX Manager

• GCVE unterstützt keine überlappenden CIDR-Bereiche in vSphere- oder
  HCX-Verwaltungsnetzwerken.

• Ein Cluster muss aus mindestens drei Nodes bestehen.

Weitere Informationen zum Verbinden mit GCVE finden Sie im Whitepaper „Privates Cloud-Netzwerk für Google Cloud VMware Engine”.

Tools für die Datenbankmigration

Es gibt mehrere Tools für die Migration von Servern nach GCVE, von denen die drei folgenden besonders häufig genutzt werden: 

VMware HCX

VMware HCX dient zur Migration von VMs aus Ihrer lokalen VMware-Umgebung in die Google Cloud VMware Engine. Dabei muss der HCX Connector OVA sowohl lokal als auch in der privaten Cloud heruntergeladen, installiert, bereitgestellt und konfiguriert werden. Die HCX Connector-Instanzen werden den lokalen vCenter-Instanzen 1:1 zugeordnet. Wenn also zehn vCenter Instanzen vorhanden sind, muss für jedes vCenter ein Connector installiert werden.

Weitere Informationen zum Migrieren von VMs aus Ihrer lokalen Umgebung in Ihre Private Cloud mit VMware HCX finden Sie hier.

Ein Hinweis zur Migration von Windows-Clustern: Die Migration von SQL Server Failover (FCI)- und anderen Windows-Clustern kann durch die Netzwerkkonnektivität, erforderliche IP-Änderungen und gemeinsam genutzte Speicherkomponenten erschwert werden. In diesen Fällen ist es oft sinnvoll, nicht das Cluster selbst zu migrieren, sondern in GCVE eine neue VM mit der benötigten Konfiguration zu erstellen und dann die Daten zu verschieben.

Datenbank-Replatforming

Manchmal lassen sich virtuelle Server nicht von der lokalen Umgebung nach GCVE migrieren, sei es weil das System zu komplex oder das Migrationstool nicht kompatibel ist. In diesem Fall empfiehlt es sich, in GCVE VM-Vorlagen zu erstellen, die das Betriebssystem, die Datenbank, die Überwachungssoftware, die erforderlichen Softwarekonfigurationen und Werkzeuge sowie Hilfsprogramme wie den Actifio Datenbank-Connector enthalten. Auf Basis dieser Vorlagen werden dann VMs als Migrationsziele für die Datenbank-Arbeitslasten bereitgestellt. Der weitere Ablauf der Migration ist von der zu Grunde liegenden Plattform und dem verfügbaren Migrationsfenster abhängig.

In dieser Tabelle sind die gängigen Datenbank-Replatforming-Strategien für die einzelnen Plattformen aufgeführt:

Bei Legacy-Datenbankplattformen wie Oracle 8i und 9i können die Datenbanken möglicherweise mit dem Stromasys Charon-Emulator auf GCVE ausgeführt werden.

Im Anschluss an die Migration der Datenbanken nach GCVE kann die Datensicherung mit Actifio konfiguriert und vSphere Replication für die Datenbankreplikation (DR) eingerichtet werden. Einen Überblick über die unterstützten Betriebssysteme und Datenbanken finden Sie in der Actifio Go Support Matrix. Wenn die zu migrierende Datenbank von Actifio nicht direkt unterstützt wird, können Sie sie mit einem datenbankspezifischen Backup-Tool (RMAN, mysqldump, pg_dump usw.) auf einem angehängten Volume sichern und dann mit Actifio in regelmäßigen Abständen ein Snapshot des Volumes mit den Sicherungskopien erstellen.

Wenn der Host überregionale Notfallwiederherstellung erfordert, wird im nächsten Schritt häufig vSphere Replication so konfiguriert, dass VMs der primären Region in die DR-Regionen repliziert werden. VMware Site Recovery Manager unterstützt die Automatisierung der Replikation und Wiederherstellung von VMs, ist aber nicht erforderlich. Mit Site Recovery Manager ist Skipterstellung und Automatisierung per VMware PowerCLI möglich.

Nach einem ersten Snapshot werden weitere Snapshots in den gemäß RPO erforderlichen Intervallen geplant. Bei einem geplanten Failover in eine DR-Region müssen wegen des Subnetzwechsels erforderliche IP-Adressänderungen und DNS-Aktualisierungen berücksichtigt werden. Je nach Datenbank ist es unter Umständen notwendig, bestimmte Datenbank-Konfigurationsdateien wie tnsnames.ora und listener.ora zu aktualisieren und an die neue Host-IP-Adresse anzupassen.  Wenn sich Personen per DNS CNAME mit Ihrer Datenbank verbinden, muss auch der CNAME-Eintrag aktualisiert werden.

Beachten Sie, dass vSphere Replication nicht alle Datenbanken unterstützt. Ob Ihre Datenbank unterstützt wird, können Sie mit der VMware 3rd Party Solution Interoperability Matrix feststellen. Wenn dies nicht der Fall ist, können Sie auf eine datenbankspezifische Funktion wie Replikation, Protokollversand, Always-On Availability Groups usw. zurückgreifen.

Die nächsten Schritte: Modernisierung und Hybride GCE/GCVE-Umgebungen

Nachdem Sie Datenbanken und Anwendungen nach GCVE migriert haben, können Sie neue Workstreams zur Anwendungs- und Datenbank-Modernisierung einleiten. So könnten Sie beispielsweise in einem nachfolgenden Modernisierungsprojekt eine Anwendung so umgestalten, dass sie teils in GCE oder GKE und teils in GCVE läuft. Auch eine hybride GCE/GCVE-Betriebsumgebung wäre möglich, in der eine Anwendung nach GCE migriert wird und die dazugehörige Datenbank in GCVE verbleibt. 

Weitere Informationen zu GCVE-Netzwerken, Konnektivitätsoptionen und gängigen Anwendungsfällen finden Sie im Beitrag ‚Privates Cloud-Netzwerk für Google Cloud VMware Engine‘ unter Private Cloud zu lokaler Umgebung, Private Cloud zu VPC und Privater Google-Zugriff.

Zusammenfassung

Die Lift-and-Shift-Migration ist eine beliebte Strategie für die Migration lokaler Datenbanken auf VMware VMs nach GCVE. Nach Abschluss des ersten Migrationsschritts können Unternehmen ihre Anwendungen und Datenbanken mit GCVE und nativen Google-Diensten nach und nach entsprechend ihren Geschäftsanforderungen transformieren.