Freigeben über

Netzwerkszenarien für den Migrationsdienst in Azure Database for PostgreSQL

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexibler Server

In diesem Artikel werden verschiedene Szenarien zum Verbinden einer Quelldatenbank mit einer Azure Database for PostgreSQL-Instanz mithilfe des Migrationsdiensts in Azure Database for PostgreSQL beschrieben. Für jedes Szenario gelten unterschiedliche Netzwerkanforderungen und -konfigurationen, um erfolgreich eine Verbindung für die Migration herzustellen. Spezifische Details variieren je nach dem tatsächlichen Netzwerksetup und den Anforderungen der Quell- und Zielumgebung.

In der folgenden Tabelle werden die Migrationsszenarien zusammengefasst. In der Tabelle ist angegeben, ob die einzelnen Szenarien basierend auf den Konfigurationen der Quell- und Zielumgebungen unterstützt wird.

PostgreSQL-Quelle Ziel Unterstützt
Lokal mit einer öffentlichen IP-Adresse Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff Ja
Lokal mit einer privaten IP-Adresse über ein virtuelles privates Netzwerk (VPN) oder Azure ExpressRoute In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
Amazon Relational Database Service (Amazon RDS) für PostgreSQL oder Amazon Aurora PostgreSQL mit einer öffentlichen IP-Adresse Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff Ja
Amazon RDS for PostgreSQL oder Amazon Aurora PostgreSQL mit privatem Zugriff über VPN oder ExpressRoute In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
Google Cloud SQL for PostgreSQL Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff Ja
Google Cloud SQL for PostgreSQL mit privatem Zugriff über VPN oder ExpressRoute In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
Installation von PostgreSQL auf einem virtuellen Azure-Computer im selben virtuellen Netzwerk oder in einem anderen virtuellen Netzwerk In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server im gleichen oder in einem anderen virtuellen Netzwerk Ja
Azure Database for PostgreSQL – Einzelserver mit öffentlichem Zugriff In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
Azure Database for PostgreSQL – Einzelserver mit privatem Endpunkt In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
Azure Database for PostgreSQL – Einzelserver mit privatem Endpunkt Azure Database for PostgreSQL – Flexibler Server mit privatem Endpunkt Ja
PostgreSQL-Quellen mit privatem Zugriff Azure Database for PostgreSQL – Flexibler Server mit privatem Endpunkt Ja
PostgreSQL-Quellen mit privatem Zugriff Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff No

Lokal (öffentliche IP-Adresse) mit flexiblem Server (öffentlicher Zugriff)

Netzwerkschritte:

  1. Stellen Sie sicher, dass der Quelldatenbankserver über eine öffentliche IP-Adresse verfügt.
  2. Konfigurieren Sie die Firewall so, dass ausgehende Verbindungen am PostgreSQL-Port (Standardport: 5432) zulässig sind.
  3. Stellen Sie sicher, dass auf den Quelldatenbankserver über das Internet zugegriffen werden kann.
  4. Testen Sie das Setup, indem Sie die Konnektivität von der Zielinstanz von Azure Database for PostgreSQL mit der Quelldatenbank sicherstellen. Vergewissern Sie sich, dass der Migrationsdienst auf die Quelldaten zugreifen kann.

Lokale Ressource (private IP-Adresse) und ein in das VNet integrierter flexibler Server (ExpressRoute oder VPN)

Screenshot: Lokales Rechenzentrum, das über ExpressRoute oder Azure VPN Gateway mit Azure verbunden ist Der lokale PostgreSQL-Server stellt über die sichere Verknüpfung eine Verbindung mit Azure Database for PostgreSQL her.

Netzwerkschritte:

  1. Richten Sie ein Site-to-Site-VPN oder eine ExpressRoute-Instanz für eine sichere, zuverlässige Verbindung zwischen dem lokalen Netzwerk und Azure ein.
  2. Konfigurieren Sie das virtuelle Azure-Netzwerk, um den Zugriff über den lokalen IP-Adressbereich zu ermöglichen.
  3. Richten Sie NSG-Regeln (Netzwerksicherheitsgruppe) ein, um Datenverkehr am PostgreSQL-Port (Standardport: 5432) aus dem lokalen Netzwerk zuzulassen.
  4. Testen Sie das Setup, indem Sie die Konnektivität von der Zielinstanz von Azure Database for PostgreSQL mit der Quelldatenbank sicherstellen. Vergewissern Sie sich, dass der Migrationsdienst auf die Quelldaten zugreifen kann.

Verwalteter PostgreSQL-Dienst (öffentliche IP-Adresse) und flexibler Server (öffentlicher/privater Zugriff)

Screenshot: PostgreSQL-Datenbank aus verwalteten Diensten (etwa Amazon oder Google), die eine Verbindung mit Azure Database for PostgreSQL über das Internet oder private Methoden herstellen

Die PostgreSQL-Quellinstanz in einem Cloudanbieter (z. B. AWS oder GCP) muss eine öffentliche IP-Adresse oder eine direkte Verbindung mit Azure haben.

Netzwerkschritte:

  • Öffentlicher Zugriff

    1. Wenn Ihre PostgreSQL-Instanz in Amazon Web Services (AWS), Google Cloud Platform (GCP) oder anderen verwalteten PostgreSQL-Diensten nicht öffentlich zugänglich ist, ändern Sie die Instanz so, dass Verbindungen von Azure zugelassen werden. Ändern Sie in der Konsole des Cloudanbieters (z. B. in AWS Management Console oder Google Cloud Console) die Einstellung, um den öffentlichen Zugriff zu ermöglichen.
    2. Fügen Sie in den Sicherheitseinstellungen des Cloudanbieters (z. B. in den Sicherheitsgruppen in AWS oder in den Firewallregeln in GCP) eine eingehende Regel hinzu, um Datenverkehr von der öffentlichen IP-Adresse oder Domäne von Azure Database for PostgreSQL zuzulassen.

  • Privater Zugriff

    1. Stellen Sie mithilfe von ExpressRoute, IPSec-VPN oder einem gleichwertigen privaten Verbindungsdienst vom Cloudanbieter (Azure ExpressRoute, AWS Direct Connect, GCP Interconnect) eine sichere Verbindung mit Azure her.
    2. Fügen Sie in den Sicherheitseinstellungen des Quellcloudanbieters (AWS-Sicherheitsgruppen, GCP-Firewall-Regeln) eine eingehende Regel hinzu, um Datenverkehr von der öffentlichen IP-Adresse oder Domäne von Azure Database for PostgreSQL oder vom IP-Adressbereich des virtuellen Azure-Netzwerks am PostgreSQL-Port (Standardport: 5432) zuzulassen.
    3. Erstellen Sie ein virtuelles Netzwerk in Azure in derselben Region, in der sich auch Ihre Instanz von Azure Database for PostgreSQL befindet. Richten Sie die Netzwerksicherheitsgruppe so ein, dass ausgehende Verbindungen mit der IP-Adresse der PostgreSQL-Instanz des Cloudanbieters am Standardport 5432 zugelassen werden.
    4. Richten Sie Netzwerksicherheitsgruppen-Regeln in Azure ein, um eingehende Verbindungen vom Cloudanbieter (z. B. von AWS oder GCP) mit dem IP-Adressbereich von Azure Database for PostgreSQL zuzulassen.
    5. Testen Sie die Konnektivität zwischen Ihrer PostgreSQL-Instanz im verwalteten PostgreSQL-Dienst (z. B. in AWS, GCP oder Heroku) und Azure Database for PostgreSQL, um sicherzustellen, dass keine Netzwerkprobleme auftreten.

Azure-VM (privater Zugriff) und Azure Database for PostgreSQL (verschiedene virtuelle Netzwerke)

In diesem Szenario wird die Konnektivität zwischen einer Instanz von Azure Virtual Machines und einer Instanz von Azure Database for PostgreSQL beschrieben, die sich in verschiedenen virtuellen Netzwerken befinden. Peering virtueller Netzwerke und entsprechende Netzwerksicherheitsgruppen-Regeln sind erforderlich, um den Datenverkehr zwischen den VNets zu unterstützen.

Screenshot: Eine Azure-VM in einem virtuellen Netzwerk stellt eine Verbindung mit Azure Database for PostgreSQL in einem anderen virtuellen Netzwerk her.

Netzwerkschritte:

  1. Richten Sie Peering virtueller Netzwerke zwischen den beiden VNets ein, um die direkte Netzwerkkonnektivität zu ermöglichen.
  2. Konfigurieren Sie Netzwerksicherheitsgruppen-Regeln, um Datenverkehr zwischen den VNets am PostgreSQL-Port zuzulassen.

Azure-VM und Azure Database for PostgreSQL (gleiches virtuelles Netzwerk)

Wenn sich eine Azure-VM und eine Instanz von Azure Database for PostgreSQL im gleichen virtuellen Netzwerk befinden, ist die Konfiguration sehr einfach. Legen Sie Netzwerksicherheitsgruppen-Regeln fest, um internen Datenverkehr am PostgreSQL-Port zuzulassen. Es sind keine anderen Firewallregeln erforderlich, da der Datenverkehr im virtuellen Netzwerk verbleibt.

Screenshot: Eine Azure-VM im selben virtuellen Netzwerk stellt eine direkte Verbindung mit der Instanz von Azure Database for PostgreSQL her.

Netzwerkschritte:

  1. Stellen Sie sicher, dass sich die VM und der PostgreSQL-Server im selben virtuellen Netzwerk befinden.
  2. Konfigurieren Sie Netzwerksicherheitsgruppen-Regeln, um Datenverkehr innerhalb des virtuellen Netzwerks am PostgreSQL-Port zuzulassen.

Einzelserver (öffentlicher Zugriff) und ein in das VNet integrierter flexibler Server

Um die Konnektivität zwischen einer Instanz von Azure Database for PostgreSQL – Einzelserver mit öffentlichem Zugriff und einem in ein VNet integrierten flexiblen Server zu erleichtern, konfigurieren Sie den Einzelserver so, dass Verbindungen von dem Subnetz zugelassen werden, in dem der flexible Server bereitgestellt wird.

Es folgt eine kurze Übersicht über die Schritte zum Einrichten dieser Konnektivität:

Fügen Sie eine VNet-Regel zu einem Einzelserver hinzu:

  1. Navigieren Sie im Azure-Portal zu Ihrer Instanz von Azure Database for PostgreSQL – Einzelserver.

  2. Wechseln Sie zu den Einstellungen für Verbindungssicherheit.

  3. Wählen Sie im Abschnitt Regeln für virtuelles Netzwerk die Option Vorhandenes virtuelles Netzwerk hinzufügen aus.

    Geben Sie an, welches virtuelle Netzwerk eine Verbindung mit Ihrem Einzelserver herstellen kann.

    Screenshot: Hinzufügen einer VNET-Regel für einen Einzelserver

Konfigurieren Sie Regeleinstellungen:

  1. Geben Sie im Konfigurationsbereich einen Namen für die neue VNET-Regel ein.

  2. Wählen Sie das Abonnement aus, in dem sich Ihr flexibler Server befindet.

  3. Wählen Sie das virtuelle Netzwerk und das dem flexiblen Server zugeordnete Subnetz aus.

  4. Wählen Sie OK aus, um die Einstellungen zu bestätigen.

    Screenshot: Zulassen des flexiblen Serversubnetzes

Nach Abschluss dieser Schritte ist der Einzelserver so eingerichtet, dass Verbindungen vom Subnetz des flexiblen Servers für eine sichere Kommunikation zwischen den beiden Servern akzeptiert werden.

Einzelserver (privater Endpunkt) und ein in das VNet integrierter flexibler Server

Gehen Sie wie folgt vor, um die Konnektivität von einer Instanz von Azure Database for PostgreSQL – Einzelserver mit einem privaten Endpunkt mit einem in ein VNet integrierten flexiblen Server zu ermöglichen:

Angeben von Details zum privaten Endpunkt:

  1. Navigieren Sie im Azure-Portal zur Instanz von Azure Database for PostgreSQL – Einzelserver. Wählen Sie den privaten Endpunkt aus, um Details zum virtuellen Netzwerk und Subnetz anzuzeigen.

  2. Wechseln Sie zum Bereich Netzwerk des flexiblen Servers. Notieren Sie sich die Informationen zu virtuellem Netzwerk und Subnetz des Servers.

    Screenshot: Verbindung des privaten Endpunkts für den Einzelserver

    Screenshot: VNet- und Subnetzdetails des privaten Endpunkts des Einzelservers

Bewerten Sie die VNET-Peeringanforderungen:

Wenn sich beide Server in unterschiedlichen VNets befinden, müssen Sie das Peering virtueller Netzwerke aktivieren, um die virtuellen Netzwerke zu verbinden. Das Peering ist optional, wenn sich die Server im gleichen virtuellen Netzwerk, aber in unterschiedlichen Subnetzen befinden. Stellen Sie sicher, dass der Datenverkehr zwischen flexiblem Server und Einzelserver nicht durch Netzwerksicherheitsgruppen blockiert wird.

Konfigurieren Sie die private DNS-Zone:

  1. Navigieren Sie zum Bereich Netzwerk für den flexiblen Server, und überprüfen Sie, ob eine private DNS-Zone konfiguriert ist. Wenn eine private DNS-Zone verwendet wird, navigieren Sie im Portal zur privaten DNS-Zone. Wählen Sie im linken Bereich die Option VNet-Verknüpfungen aus, und überprüfen Sie, ob das virtuelle Netzwerk des Einzelservers und des flexiblen Servers in dieser Liste angezeigt wird.

    Screenshot: Virtuelles Netzwerk, das mit einer privaten DNS-Zone verknüpft ist

    Wird keine private DNS-Zone verwendet, wählen Sie die Schaltfläche Hinzufügen aus, und erstellen Sie für die VNets des Einzelservers und des flexiblen Servers eine Verknüpfung mit dieser privaten DNS-Zone.

  2. Navigieren Sie zum privaten Endpunkt für Ihren Einzelserver, und wählen Sie den Bereich DNS-Konfiguration aus. Überprüfen Sie, ob an diesen Endpunkt eine private DNS-Zone angefügt ist. Falls nicht, fügen Sie eine private DNS-Zone an, indem Sie die Schaltfläche Konfiguration hinzufügen auswählen.

    Screenshot: Private DNS-Zone, die mit einem privaten Endpunkt verwendet wird

  3. Wählen Sie die private DNS-Zone auf dem privaten Endpunkt Ihres Einzelservers aus. Überprüfen Sie, ob die VNets des Einzelservers und des flexiblen Servers in den VNet-Verknüpfungen angezeigt werden. Wenn dies nicht der Fall ist, führen Sie die zuvor beschriebenen Schritte aus, um die Verknüpfungen mit den virtuellen Netzwerken des Einzelservers und des flexiblen Servers zu dieser privaten DNS-Zone hinzuzufügen.

  4. Navigieren Sie zur abschließenden Überprüfung zur privaten DNS-Zone des privaten Endpunkts für Ihren Einzelserver, und überprüfen Sie, ob ein A-Datensatz für Ihren Einzelserver vorhanden ist, der auf eine private IP-Adresse verweist.

    Screenshot: Private IP-Adresse, die einem privaten Endpunkt zugewiesen ist

Wenn Sie diese Schritte ausführen, kann die Instanz von Azure Database for PostgreSQL – Flexibler Server eine Verbindung mit der Instanz von Azure Database for PostgreSQL – Einzelserver herstellen.

Einzelserver (privater Endpunkt) und flexibler Server (privater Endpunkt)

In diesem Abschnitt werden die wesentlichen Netzwerkschritte beschrieben, die zum Migrieren von einem Einzelserver mit einem privaten Endpunkt zu einem flexiblen Server mit einem privaten Endpunkt in Azure Database for PostgreSQL ausgeführt werden müssen. Dies umfasst die Integration eines Runtimeserver-VNet mit einem privaten Endpunkt. Weitere Informationen finden Sie unter Runtimeserver für die Migration mit dem Migrationsdienst in Azure Database for PostgreSQL.

  • Sammeln Sie Details zum privaten Endpunkt für den Einzelserver:

    1. Navigieren Sie im Azure-Portal zur Instanz von Azure Database for PostgreSQL – Einzelserver.
    2. Erfassen Sie die VNet- und Subnetzdetails, die unter der privaten Endpunktverbindung des Einzelservers aufgeführt sind.

    Screenshot: Einzelserver mit privatem Endpunkt

  • Sammeln Sie Details zum privaten Endpunkt für den flexiblen Server:

    1. Navigieren Sie im Azure-Portal zur Instanz von Azure Database for PostgreSQL – Flexibler Server.
    2. Erfassen Sie die VNet- und Subnetzdetails, die unter der privaten Endpunktverbindung des flexiblen Servers aufgeführt sind.

    Screenshot: Flexibler Server mit einem privaten Endpunkt

  • Sammeln Sie VNet-Details für den Runtimeserver für die Migration:

    1. Navigieren Sie im Azure-Portal zum Runtimeserver für die Migration. Das heißt, Sie müssen zu der in das VNet integrierten Instanz von Azure Database for PostgreSQL – Flexibler Server navigieren.
    2. Erfassen Sie die VNet- und Subnetzdetails, die unter dem virtuellen Netzwerk aufgeführt sind.

    Screenshot: Runtimeserver für die Migration mit virtuellem Netzwerk

  • Bewerten Sie die VNET-Peeringanforderungen:

    1. Aktivieren Sie das Peering virtueller Netzwerke, wenn sich die Server in verschiedenen VNets befinden. Das Peering ist nicht erforderlich, wenn sich die Server im gleichen virtuellen Netzwerk, aber in unterschiedlichen Subnetzen befinden.
    2. Stellen Sie sicher, dass der Datenverkehr zwischen dem Quellserver, dem Runtimeserver für die Migration und dem Zielserver nicht durch Netzwerksicherheitsgruppen blockiert wird.

  • Konfiguration der privaten DNS-Zone:

    1. Navigieren Sie zum Bereich Netzwerk für den flexiblen Server, und überprüfen Sie, ob eine private DNS-Zone konfiguriert ist.

    2. Wenn eine private DNS-Zone verwendet wird, navigieren Sie im Portal zur privaten DNS-Zone. Wählen Sie im linken Bereich die Option VNet-Verknüpfungen aus, und überprüfen Sie, ob das virtuelle Netzwerk des Einzelservers und des flexiblen Servers in dieser Liste angezeigt wird.

      Screenshot: Private DNS-Zone des Runtimeservers

    3. Fügen Sie eine private DNS-Zone an den privaten Endpunkt des Einzelservers an, sofern noch nicht konfiguriert:

      1. Fügen Sie der privaten DNS-Zone VNet-Verknüpfungen für den Einzelserver und den Runtimeserver für die Migration hinzu.
      2. Wiederholen Sie das Anfügen der DNS-Zone sowie den VNet-Verknüpfungsprozess für den privaten Endpunkt des flexiblen Servers.

      Screenshot: Private DNS-Zone, die den Quellserver und den Zielserver enthält

Bei Verwendung eines benutzerdefinierten DNS-Servers oder benutzerdefinierter DNS-Namespaces können Sie alternativ das Feld für einen benutzerdefinierten FQDN bzw. für eine benutzerdefinierte IP-Adresse verwenden, anstatt eine private DNS-Zone zu verknüpfen. Mit diesem Setup können Sie FQDNs oder IP-Adressen direkt auflösen, ohne eine private DNS-Zone integrieren zu müssen.

PostgreSQL-Quelle (private IP-Adresse) und flexibler Server (privater Endpunkt)

In diesem Abschnitt werden die Netzwerkschritte für die Migration einer PostgreSQL-Datenbank von einem cloudbasierten PostgreSQL-Dienst, einem lokalen Setup oder einer VM (jeweils mit privaten IP-Adressen) zu einer Instanz von Azure Database for PostgreSQL – Flexibler Server beschrieben, die mit einem privaten Endpunkt geschützt ist. Bei der Migration wird eine sichere Datenübertragung innerhalb eines privaten Netzwerkraums sichergestellt. Für lokale Verbindungen wird dabei ein Azure VPN oder ExpressRoute verwendet, während für Cloud-zu-Cloud-Migrationen das Peering virtueller Netzwerke oder ein VPN verwendet wird. Weitere Informationen finden Sie unter Runtimeserver für die Migration mit dem Migrationsdienst in Azure Database for PostgreSQL.

  • Stellen Sie eine Netzwerkverbindung her:

    1. Richten Sie für lokale Quellen ein Site-to-Site-VPN oder ExpressRoute ein, um Ihr lokales Netzwerk mit dem virtuellen Netzwerk von Azure zu verbinden.
    2. Stellen Sie für eine Azure-VM, für eine Amazon-Instanz oder für eine Google Compute Engine-Instanz sicher, dass das Peering virtueller Netzwerke, ein VPN-Gateway oder eine ExpressRoute-Instanz vorhanden ist, um eine sichere Verbindung mit dem virtuellen Netzwerk von Azure herzustellen.

  • Sammeln Sie VNet-Details für den Runtimeserver für die Migration:

    1. Navigieren Sie im Azure-Portal zum Runtimeserver für die Migration. Das heißt, Sie müssen zu der in das VNet integrierten Instanz von Azure Database for PostgreSQL – Flexibler Server navigieren.
    2. Erfassen Sie die VNet- und Subnetzdetails, die unter dem virtuellen Netzwerk aufgeführt sind.

  • Bewerten Sie die VNET-Peeringanforderungen:

    1. Aktivieren Sie das Peering virtueller Netzwerke, wenn sich die Server in verschiedenen VNets befinden. Das Peering ist nicht erforderlich, wenn sich die Server im gleichen virtuellen Netzwerk, aber in unterschiedlichen Subnetzen befinden.
    2. Stellen Sie sicher, dass der Datenverkehr zwischen dem Quellserver, dem Runtimeserver für die Migration und dem Zielserver nicht durch Netzwerksicherheitsgruppen blockiert wird.

  • Konfiguration der privaten DNS-Zone:

    1. Vergewissern Sie sich im Bereich Netzwerk des Runtimeservers für die Migration, dass eine private DNS-Zone verwendet wird.
    2. Stellen Sie sicher, dass sowohl die VNets für die Quelle als auch der flexible Zielserver mit der privaten DNS-Zone des Runtimeservers für die Migration verknüpft sind.
    3. Fügen Sie eine private DNS-Zone an den privaten Endpunkt des flexiblen Servers an, sofern noch nicht konfiguriert.
    4. Fügen Sie der privaten DNS-Zone VNet-Verknüpfungen für den flexiblen Server und für den Runtimeserver für die Migration hinzu.

Bei Verwendung eines benutzerdefinierten DNS-Servers oder benutzerdefinierter DNS-Namespaces können Sie alternativ das Feld für einen benutzerdefinierten FQDN bzw. für eine benutzerdefinierte IP-Adresse verwenden, anstatt eine private DNS-Zone zu verknüpfen. Mit diesem Setup können Sie FQDNs oder IP-Adressen direkt auflösen, ohne eine private DNS-Zone integrieren zu müssen.

Zugehöriger Inhalt