Netzwerkverbindung für homogene PostgreSQL-Standardmigrationen

Auf dieser Seite finden Sie eine Übersicht über die Konzepte im Zusammenhang mit der Konfiguration der Netzwerkverbindung für homogene PostgreSQL-Standardmigrationen zu AlloyDB for PostgreSQL. Informationen zur Konnektivität bei der Schnellstart-Migration finden Sie im Leitfaden Schnellstart-Migrationen verwenden.

Nachdem Sie sich mit den verschiedenen Verbindungsmethoden und ihren Anforderungen vertraut gemacht haben, können Sie das Entscheidungsbaumdiagramm verwenden, um die richtige Lösung für Ihr Szenario auszuwählen.

Am Migrationsprozess beteiligte Netzwerkkomponenten

Bei homogenen PostgreSQL-Migrationen zu AlloyDB for PostgreSQL stellt der Database Migration Service eine Verbindung zum Zielcluster von AlloyDB for PostgreSQL her und verwaltet dann den Migrationsprozess in seinem Namen. Der Zielcluster stellt die Verbindung zur Quellinstanz her, während Database Migration Service den Prozess überwacht.

PostgreSQL-Migrationsablauf – Übersicht
Abbildung 1. Datenverschiebung während Migrationen mit Database Migration Service for PostgreSQL. (Zum Vergrößern klicken)
PostgreSQL-Migrationsablauf – Übersicht

Wenn Sie die Einrichtung der Netzwerkverbindung für Ihre Migration planen, sollten Sie die Infrastrukturanforderungen sorgfältig berücksichtigen. Dazu gehören auch die Einschränkungen, die Ihre Netzwerkentscheidungen für den Endzustand des migrierten Datenbankclusters mit sich bringen könnten. Wenn Sie beispielsweise eine private Verbindung für Ihre Netzwerkverbindung verwenden möchten, müssen Sie einen AlloyDB for PostgreSQL-Zielcluster verwenden, der mit Zugriff auf private Dienste oder Private Service Connect konfiguriert ist.

Verfügbarkeit von Verbindungsmethoden

Je nachdem, ob Sie zu einem neuen oder einem vorhandenen Zielcluster migrieren, sind für verschiedene Quelldatenbanken unterschiedliche Verbindungsmethoden verfügbar. In der folgenden Tabelle finden Sie eine Übersicht darüber, welches Szenario welche Methode unterstützt:

Quelldatenbankangebot Methoden für Migrationen zu neuen Zielclustern Methoden für Migrationen zu vorhandenen Zielclustern
Selbst gehostet IP-Zulassungsliste, umgekehrter SSH-Tunnel, VPC-Peering, TCP-Proxy über eine in der Cloud gehostete VM IP-Zulassungsliste, umgekehrter SSH-Tunnel, VPC-Peering (erfordert einen PSA-Zielcluster), TCP-Proxy über eine in der Cloud gehostete VM, PSC-Schnittstellen (erfordert einen PSC-fähigen Zielcluster)
Amazon Aurora, Amazon RDS IP-Zulassungsliste, umgekehrter SSH-Tunnel, VPC-Peering IP-Zulassungsliste, umgekehrter SSH-Tunnel, VPC-Peering (erfordert einen PSA-Zielcluster), PSC-Schnittstellen (erfordert einen PSC-fähigen Zielcluster)
Cloud SQL for PostgreSQL IP-Zulassungsliste (nicht empfohlen), VPC-Peering, TCP-Proxy über eine in der Cloud gehostete VM IP-Zulassungsliste (nicht empfohlen), VPC-Peering, TCP-Proxy über eine in der Cloud gehostete VM, PSC-Schnittstellen (erfordert einen PSC-fähigen Zielcluster)

Vergleich der Verbindungsmethoden

Jede Verbindungsmethode hat unterschiedliche Vorteile und Anforderungen. In den folgenden Tabellen finden Sie einen Überblick über die verschiedenen Methoden. Weitere Informationen zu den einzelnen Methoden finden Sie in den entsprechenden Abschnitten.

Netzwerkmethode Vorteile Nachteile
IP-Zulassungsliste
  • Die am einfachsten einzurichtende Verbindungsmethode.
  • Nützlich, wenn Ihre Quelldatenbank nicht über private Netzwerke in Google Clouderreicht werden kann.
  • Erfordert, dass Sie eine IPv4-Adresse Ihres Quelldatenbankservers im öffentlichen Internet verfügbar machen. Dies erfordert zusätzliche Sicherheitsmaßnahmen. Wir empfehlen beispielsweise, TLS-Zertifikate und Firewallregeln zu verwenden, um die Verbindung zu sichern.
  • Für die Konfiguration der Firewallregeln ist möglicherweise die Unterstützung der Abteilung für Netzwerksicherheit oder IT erforderlich.
Umgekehrter SSH-Tunnel
  • Sicherer als die Verbindung über eine öffentliche IP-Adresse mit einer IP-Zulassungsliste.

    Die erste Verbindung wird über Secure Shell-Ports (SSH) über das öffentliche Internet hergestellt. Sobald die Verbindung aktiv ist, wird der gesamte Traffic über einen sicheren, privaten Tunnel an den PostgreSQL-Port 5432 geleitet.

  • Nützlich, wenn Ihre Quelldatenbank nicht über private Netzwerke in Google Clouderreichbar ist, Sie Ihren Quelldatenbankserver aber nicht direkt dem öffentlichen Internet zugänglich machen möchten.
  • Die Verwendung eines Zwischenservers (der Reverse-SSH-Tunnel-Maschine) für die Verbindung kann zu zusätzlicher Latenz führen.
  • Sie müssen den Reverse-SSH-Hostserver einrichten und verwalten. Der Server muss während der gesamten Migration online bleiben.
Private Service Connect-Schnittstellen
  • Stellt mithilfe eines Netzwerkanhangs Verbindungen zur privaten IP-Adresse der Quelle her. Bei dieser Methode wird kein Peering-Kontingent in Ihrer VPC verbraucht.
  • Die am einfachsten zu konfigurierende und empfohlene Methode für private Konnektivität zur Quelle.
  • Wird nur für Migrationen zu vorhandenen AlloyDB for PostgreSQL-Zielclustern unterstützt. Wenn Sie diese Methode verwenden möchten, müssen Sie den Zielcluster direkt in AlloyDB for PostgreSQL erstellen.
  • Erfordert das Einrichten eines Netzwerkanhangs und das Anpassen von Firewallregeln.
  • Sie können den Netzwerkanhang nach dem Herstellen der Verbindung nicht mehr ändern.
TCP-Proxy über eine in der Cloud gehostete VM
  • Überbrückt private Verbindungen, wenn ein direktes Routing aufgrund von nicht transitivem VPC-Peering nicht möglich ist (z. B. bei der Migration von Cloud SQL for PostgreSQL-Quellen, die die ältere Producer-Netzwerkarchitektur verwenden, oder beim Überbrücken separater VPC-Netzwerke).
  • Database Migration Service generiert automatisch ein Setupscript, um die Proxy-VM bereitzustellen und zu konfigurieren.
  • Sie müssen die Compute Engine-Proxy-VM einrichten und verwalten, was zusätzliche Rechenkosten verursachen kann.
Private Konnektivität mit Virtual Private Cloud-Peering Die Verbindung wird über VPC-Peerings zur privaten IP-Adresse Ihrer Quelldatenbank hergestellt. Wenn Ihre VPC nicht über genügend Peering-Kontingent verfügt, kann es schwierig sein, diese Verbindungsmethode zu verwenden. Für die meisten Szenarien, in denen Sie zu einem vorhandenen AlloyDB for PostgreSQL-Cluster migrieren, empfehlen wir stattdessen die Verwendung von privater Konnektivität mit Private Service Connect-Schnittstellen.

IP-Zulassungsliste für die Verbindung zur Quelldatenbank

Wenn Sie die Verbindungsmethode „IP-Zulassungsliste“ verwenden, versucht AlloyDB for PostgreSQL, eine Verbindung zu einer öffentlich verfügbaren IP-Adresse Ihres Quelldatenbankservers über den PostgreSQL-Port 5432 herzustellen.

Diagramm, das die Verbindung über eine öffentliche IP-Zulassungsliste für homogene Migrationen zeigt.
Abbildung 2. Diagramm zur Netzwerkverbindung mit IP-Zulassungsliste für homogene PostgreSQL-Migrationen. (Zum Vergrößern klicken)
Diagramm, das die Verbindung über eine öffentliche IP-Zulassungsliste für homogene Migrationen zeigt.

Anforderungen für die Verbindung über eine IP-Zulassungsliste

Auf übergeordneter Ebene müssen Sie für diese Verbindungsmethode Folgendes sicherstellen:

  • Sie müssen die IP-Adresse Ihrer Quelldatenbank im öffentlichen Internet verfügbar machen (entweder direkt oder mit einem öffentlich erkannten Hostnamen über einen Domain Name Server (DNS)).

  • Für die primäre AlloyDB for PostgreSQL-Zielinstanz muss eine ausgehende öffentliche IP-Adresse aktiviert sein. Ihre Quelldatenbank muss eingehende Verbindungen von beiden ausgehenden öffentlichen IP-Adressen der primären Zielinstanz zulassen.

Verbindung über IP-Zulassungsliste konfigurieren

Die Konfiguration der Verbindung über öffentliche IP-Adressen erfordert je nach Typ der Quelldatenbank unterschiedliche Schritte. Weitere Informationen finden Sie unter:

Datenbankverbindung über umgekehrten SSH-Tunnel

Diese Verbindungsmethode ist eine Mischung aus öffentlicher und privater Netzwerkverbindung. Die Verbindung selbst wird über Secure Shell-Ports (SSH) zur öffentlichen IP-Adresse des Tunnelhostservers hergestellt. Sobald die Verbindung aktiv ist, wird der gesamte Traffic über einen sicheren Tunnel an die private IP-Adresse Ihrer Quelldatenbank an Port 5432 geleitet.

Für Cloud SQL-Quellen oder selbst gehostete Lösungen, die sich in Google Cloudbefinden, empfehlen wir die Verwendung von privater Konnektivität mit Private Service Connect-Schnittstellen oder privater Konnektivität mit Virtual Private Cloud-Peering.

Ein Netzwerkdiagramm, das eine allgemeine Konnektivitätseinrichtung über einen dedizierten SSH-Server zeigt.
Abbildung 3. Beispiel für ein Migrationsnetzwerk: Quellverbindung über einen SSH-Tunnel. (Zum Vergrößern klicken)
Ein Netzwerkdiagramm, das eine allgemeine Konnektivitätseinrichtung über einen dedizierten SSH-Server zeigt.

Anforderungen für umgekehrte SSH-Tunnel

Zum Erstellen der Verbindung müssen Sie SSH-Ports auf Ihrem Tunnelserver (auch als Bastion Host bezeichnet) für das öffentliche Internet freigeben. Sobald die Verbindung hergestellt ist, wird der gesamte Traffic über die private Tunnelverbindung weitergeleitet.

Für diese Methode sind zusätzliche Netzwerkkomponenten erforderlich:

  • Eine virtuelle Maschine (VM) in Google Cloud , die als Reverse-SSH-Maschine dient.
  • Eine zusätzliche Maschine in Ihrem Netzwerk, die eine Verbindung zur Quelldatenbank hat.

Verbindung für umgekehrten SSH-Tunnel konfigurieren

Database Migration Service kann ein Setupscript generieren, um die Reverse-SSH-VM zu erstellen. Der vollständige End-to-End-Prozess unterscheidet sich jedoch je nach Typ der Quelldatenbank. Weitere Informationen finden Sie unter Reverse-SSH-Verbindung konfigurieren.

Private Konnektivität mit Private Service Connect-Schnittstellen

Mit dieser Verbindungsmethode können Sie eine Verbindung zur privaten IP-Adresse Ihrer Quelldatenbank herstellen, ohne das VPC-Peering-Kontingent zu verbrauchen. Private Service Connect-Schnittstellen sind die empfohlene Methode für private IP-Verbindungen, aber sie sind nur verfügbar, wenn Sie zu einem vorhandenen Cluster migrieren.

Wenn Sie Private Service Connect-Schnittstellen verwenden, verbraucht Ihr Zielcluster kein zusätzliches Peering-Kontingent. Stattdessen wird die Private Service Connect-Schnittstelle verwendet, um die Virtual Private Cloud zu erreichen, in der die private IP-Adresse Ihrer Quelldatenbank erreichbar ist. Je nach Netzwerkarchitektur müssen Sie möglicherweise zusätzliche Komponenten wie Cloud VPN oder Cloud Interconnect verwenden.

Diagramm, das die Private Service Connect-Konnektivität mit Cloud VPN für homogene Migrationen zeigt.
Abbildung 4. Netzwerkverbindung mit Private Service Connect-Schnittstellen für homogene Migrationen von Quellen außerhalb von Google Cloud. (Zum Vergrößern klicken)
Diagramm, das die Private Service Connect-Konnektivität mit Cloud VPN für homogene Migrationen zeigt.

Bei Migrationen von Cloud SQL for PostgreSQL-Instanzen muss der Zugriff auf private Dienste für die Quellinstanz aktiviert sein und sie muss mit der Virtual Private Cloud, in der Sie den Netzwerkanhang erstellen, per Peering verbunden sein. Der AlloyDB for PostgreSQL-Zielcluster verbraucht jedoch kein zusätzliches Peering-Kontingent. Stattdessen wird die Private Service Connect-Schnittstelle verwendet.

Diagramm, das die Netzwerkverbindung für Migrationen mit Private Service Connect-Schnittstellen zeigt.
Abbildung 5: Netzwerkverbindung mit Private Service Connect-Schnittstellen für homogene Migrationen von Cloud SQL for PostgreSQL. (Zum Vergrößern klicken)
Diagramm, das die Netzwerkverbindung für Migrationen mit Private Service Connect-Schnittstellen zeigt.

Anforderungen für Private Service Connect-Schnittstellen

Für diese Verbindungsmethode ist Folgendes erforderlich:

  • Der Zieldatenbankcluster muss ein AlloyDB for PostgreSQL-Cluster mit aktiviertem PSC sein.

  • Sie benötigen ein VPC-Netzwerk (Virtual Private Cloud) mit aktiviertem Zugriff auf private Dienste.

    Dies ist das Netzwerk, in dem Sie den Netzwerkanhang erstellen. Die IP-Adresse Ihrer Quelldatenbank muss über diese Virtual Private Cloud erreichbar sein. Bei Cloud SQL for PostgreSQL-Quellen ist dies beispielsweise das Netzwerk, das Sie mit der PSA-fähigen Cloud SQL-Quellinstanz peeren.

Private IP-Verbindungen mit Private Service Connect-Schnittstellen konfigurieren

Wenn Sie private IP-Verbindungen mit Private Service Connect-Schnittstellen verwenden möchten, muss die private IP-Adresse Ihrer Quelldatenbank über Ihre Virtual Private Cloud erreichbar sein. Je nach Netzwerkarchitektur müssen Sie möglicherweise zusätzliche Komponenten wie Cloud VPN oder Cloud Interconnect verwenden.

Weitere Informationen zum Konfigurieren privater IP-Verbindungen für verschiedene Datenbankquellen finden Sie hier:

TCP-Proxy über eine in der Cloud gehostete VM

Diese Verbindungsmethode ist eine Alternative, wenn Sie eine private Verbindung über Virtual Private Cloud-Peering verwenden möchten, aber nicht transitives VPC-Peering ein direktes Routing zwischen Ihrer Quelldatenbank und Ihrem AlloyDB for PostgreSQL-Zielcluster verhindert.

Dieses Szenario tritt am häufigsten auf, wenn Sie von einer Cloud SQL for PostgreSQL-Instanz, die die ältere Erstellernetzwerkarchitektur verwendet, zu einem AlloyDB for PostgreSQL-Zielcluster migrieren, der mit Zugriff auf private Dienste (PSA) konfiguriert ist. Da sich beide Dienste in separaten, von Google verwalteten Erstellernetzwerken befinden und VPC-Peering nicht transitiv ist, kann der Traffic nicht direkt zwischen ihnen fließen. Sie gilt auch, wenn sich Ihre selbst gehostete Quelldatenbank und der AlloyDB for PostgreSQL-Zielcluster in separaten Peering-VPC-Netzwerken befinden oder wenn die Richtlinienanforderungen des Unternehmens erfordern, dass der Migrations-Traffic über eine einzelne statische interne IP-Adresse geleitet wird.

Eine Zwischen-Compute Engine-VM in Ihrem VPC-Netzwerk fungiert als Brücke. Sie akzeptiert eingehende Replikationsverbindungen auf Port 5432 von der AlloyDB for PostgreSQL-Zielprimärinstanz und leitet sie an die Quelldatenbank weiter.

Ein Architekturdiagramm für eine private Datenbankverbindung, die die TCP-Proxy-VM verwendet.
Abbildung 6. Eine private Verbindung, die von der TCP-Proxy-VM ermöglicht wird. (Zum Vergrößern klicken)
Ein Architekturdiagramm für eine private Datenbankverbindung, die die TCP-Proxy-VM verwendet.

Anforderungen für die TCP-Proxy-Verbindung

Für diese Verbindungsmethode ist Folgendes erforderlich:

  • Eine Compute Engine-VM im Virtual Private Cloud-Netzwerk, die mit Ihrem AlloyDB for PostgreSQL-Zielcluster per Peering verbunden ist, um den TCP-Proxy-Container auszuführen.
  • Netzwerkerreichbarkeit von der Proxy-VM zu Ihrer Quelldatenbankinstanz.

TCP-Proxy-Verbindung konfigurieren

Wenn Sie einen Migrationsjob in der Google Cloud Console erstellen, erfasst Database Migration Service die erforderlichen Parameter und generiert ein gcloud-Skript, das die Compute Engine-Proxy-Container-VM und die erforderliche Firewallregel für eingehenden Traffic in Ihrer VPC erstellt. Eine detaillierte Anleitung finden Sie unter Konnektivität mit einem TCP-Proxy über eine in der Cloud gehostete VM konfigurieren.

Private Konnektivität mit VPC-Peering

Mit dieser Methode können Sie über die privaten IP-Adressen in Ihrer Virtual Private Cloud (VPC) eine Verbindung zu Ihrer Quelle herstellen. Sie müssen keine Schnittstellen für das öffentliche Internet freigeben, um diese Methode zu verwenden. Allerdings muss die IP-Adresse oder der Hostname Ihrer Quelldatenbank von Ihrer Google Cloud -VPC aus erreichbar sein. Für Quellen, die sich außerhalb von Google Cloudbefinden, benötigen Sie möglicherweise zusätzliche Netzwerkkomponenten wie Cloud VPN oder Cloud Interconnect.

Diagramm, das die Virtual Private Cloud-Peering-Konnektivität für homogene PostgreSQL-Migrationen zeigt.
Abbildung 7. Netzwerkverbindung mit Virtual Private Cloud-Peering für homogene PostgreSQL-Migrationen. (Zum Vergrößern klicken)
Diagramm, das die Virtual Private Cloud-Peering-Konnektivität für homogene PostgreSQL-Migrationen zeigt.

Anforderungen für private IP-Verbindungen mit VPC-Peering

Für die private IP-Verbindung mit VPC-Peering ist Folgendes erforderlich:

Private IP-Verbindung mit VPC-Peering konfigurieren

Wenn Sie eine private IP-Verbindung mit Virtual Private Cloud-Peering verwenden möchten, muss die private IP-Adresse Ihrer Quelldatenbank von Ihrer Virtual Private Cloud aus erreichbar sein. Je nach Netzwerkarchitektur müssen Sie möglicherweise zusätzliche Komponenten wie Cloud VPN oder Cloud Interconnect verwenden.

Weitere Informationen zum Konfigurieren privater IP-Verbindungen für verschiedene Datenbankquellen finden Sie hier:

Entscheidungsbaum für Netzwerkverbindungen

Wenn Sie mit allen unterstützten Verbindungsmethoden und ihren Anforderungen vertraut sind, können Sie die Fragen im Diagramm durchgehen, um die richtige Verbindungsmethode für Ihr Szenario auszuwählen.

Ein Entscheidungsbaumdiagramm mit Leitfragen, die Ihnen bei der Auswahl der richtigen Verbindungsmethode helfen.
Abbildung 8. Entscheidungsbaum für die Netzwerkverbindung der Quelle.

Nächste Schritte