Netzwerkhandbuch für den Migrationsdienst in Azure Database for PostgreSQL

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

In diesem Dokument werden verschiedene Szenarien zum Verbinden einer Quelldatenbank mit einer Azure Database for PostgreSQL-Instanz mithilfe des Migrationsdiensts beschrieben. Jedes Szenario stellt unterschiedliche Netzwerkanforderungen und -konfigurationen dar, um eine erfolgreiche Verbindung für die Migration herzustellen. Spezifische Details variieren je nach dem tatsächlichen Netzwerksetup und den Anforderungen der Quell- und Zielumgebungen.

In der Tabelle sind die Szenarien für das Verbinden einer Quelldatenbank mit Azure Database for PostgreSQL mithilfe des Migrationsdiensts zusammengefasst. Es wird angegeben, ob jedes Szenario basierend auf den Konfigurationen der Quell- und Zielumgebungen unterstützt wird.

PostgreSQL-Quelle Ziel Unterstützt
Lokal mit öffentlicher IP-Adresse Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff Ja
Lokal mit privater IP-Adresse über VPN/ExpressRoute In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
AWS RDS für PostgreSQL mit öffentlicher IP-Adresse Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff Ja
AWS RDS für PostgreSQL mit privatem Zugriff über VPN/ExpressRoute In das VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server Ja
Azure-VM mit PostgreSQL-Installation im gleichen 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
Lokal/Azure-VM/AWS mit privatem Zugriff Azure Database for PostgreSQL – Flexibler Server mit privatem Endpunkt Ja
Lokal/Azure-VM/AWS mit privatem Zugriff Azure Database for PostgreSQL – Flexibler Server mit öffentlichem Zugriff No

Szenario 1: Lokale Quelle für Azure Database for PostgreSQL mit öffentlichem Zugriff

Netzwerkschritte:

  • Der Quelldatenbankserver muss über eine öffentliche IP-Adresse verfügen.
  • Konfigurieren Sie die Firewall so, dass ausgehende Verbindungen auf dem PostgreSQL-Port (Standard 5432) zulässig sind.
  • Stellen Sie sicher, dass auf den Quelldatenbankserver über das Internet zugegriffen werden kann.
  • Überprüfen Sie die Netzwerkkonfiguration, indem Sie die Konnektivität vom Azure Database for PostgreSQL-Ziel zur Quelldatenbank testen und bestätigen, dass der Migrationsdienst auf die Quelldaten zugreifen kann.

Szenario 2: Private IP-Adresse der lokale Quelle zur im virtuellen Netzwerk integrierten Azure Database for PostgreSQL-Instanz über Express Route/IPSec-VPN

Screenshot: Das lokale Rechenzentrum ist über ExpressRoute oder VPN Gateway mit Azure verbunden. Der lokale PostgreSQL-Server verbindet sich über die sichere Verknüpfung mit Azure Database for PostgreSQL.

Netzwerkschritte:

  • Richten Sie ein Site-to-Site-VPN oder ExpressRoute für eine sichere, zuverlässige Verbindung zwischen dem lokalen Netzwerk und Azure ein.
  • Konfigurieren Sie Virtual Network (virtuelles Netzwerk) von Azure, um den Zugriff über den lokalen IP-Adressbereich zu ermöglichen.
  • Richten Sie Regeln für die Netzwerksicherheitsgruppe (NSG) ein, um Datenverkehr im PostgreSQL-Port (Standard 5432) aus dem lokalen Netzwerk zuzulassen.
  • Überprüfen Sie die Netzwerkkonfiguration, indem Sie die Konnektivität vom Azure Database for PostgreSQL-Ziel zur Quelldatenbank testen und bestätigen, dass der Migrationsdienst auf die Quelldaten zugreifen kann.

Szenario 3: AWS RDS für PostgreSQL zu Azure Database for PostgreSQL

Screenshot: AWS RDS for PostgreSQL stellt über das Internet oder einen Direktverbindungsdienst wie Express Route oder AWS Direct Connect eine Verbindung mit Azure Database for PostgreSQL her.

Die Quelldatenbank in einem anderen Cloudanbieter (AWS) muss über eine öffentliche IP-Adresse oder eine direkte Verbindung mit Azure verfügen.

Netzwerkschritte:

  • Öffentlicher Zugriff:

    • Wenn Ihre AWS RDS-Instanz nicht öffentlich zugänglich ist, können Sie die Instanz so ändern, dass Verbindungen von Azure zugelassen werden. Dies kann über die AWS-Verwaltungskonsole erfolgen, indem Sie die Einstellung „Öffentlich Zugänglich“ auf „Ja“ ändern.
    • Fügen Sie in der AWS RDS-Sicherheitsgruppe eine eingehende Regel hinzu, um Datenverkehr aus der öffentliche IP-Adresse/Domäne von Azure Database for PostgreSQL zuzulassen.
  • Privater Zugriff

    • Stellen Sie eine sichere Verbindung mithilfe von ExpressRoute oder mithilfe eines VPN zwischen AWS und Azure her.
    • Fügen Sie in der AWS RDS-Sicherheitsgruppe eine eingehende Regel hinzu, um Datenverkehr aus der öffentlichen IP-Adresse/Domäne von Azure Database for PostgreSQL oder dem Bereich der IP-Adressen im virtuellen Azure-Netzwerk im PostgreSQL-Port (Standard 5432) zuzulassen.
    • Erstellen Sie ein Azure Virtual Network (virtuelles Netzwerk), in dem sich Ihre Azure Database for PostgreSQL-Instanz befindet. Konfigurieren Sie die Network Security Group (NSG) des virtuellen Netzwerks, um ausgehende Verbindungen mit der IP-Adresse der AWS-RDS-Instanz im PostgreSQL-Port zuzulassen.
    • Richten Sie NSG-Regeln in Azure ein, um eingehende Verbindungen vom Cloudanbieter, AWS RDS IP-Adressbereich, zuzulassen.
    • Testen Sie die Konnektivität zwischen AWS RDS und Azure Database for PostgreSQL, um sicherzustellen, dass keine Netzwerkprobleme vorliegen.

Szenario 4: Azure-VMs zu Azure Database for PostgreSQL (verschiedene virtuelle Netzwerke)

In diesem Szenario wird die Konnektivität zwischen Azure-VMs und einer Azure Database for PostgreSQL-Instanz beschrieben, die sich in unterschiedlichen virtuellen Netzwerken befindet. Peering virtueller Netzwerke und entsprechende NSG-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:

  • Richten Sie Peering virtueller Netzwerke zwischen den beiden VNets ein, um die direkte Netzwerkkonnektivität zu ermöglichen.
  • Konfigurieren Sie NSG-Regeln, um Datenverkehr zwischen den VNets auf dem PostgreSQL-Port zuzulassen.

Szenario 5: Azure-VMs zu Azure PostgreSQL (gleiches virtuelles Netzwerk)

Wenn sich Azure-VM und Azure Database for PostgreSQL im gleichen virtuellen Netzwerk befinden, ist die Konfiguration sehr einfach. NSG-Regeln müssen so festgelegt werden, dass interner Datenverkehr am PostgreSQL-Port zugelassen wird. Zusätzliche Firewallregeln sind für die Azure Database for PostgreSQL-Instanz nicht erforderlich, da der Datenverkehr das virtuelle Netzwerk nicht verlässt.

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

Netzwerkschritte:

  • Stellen Sie sicher, dass sich die VM und der PostgreSQL-Server im selben virtuellen Netzwerk befinden.
  • Konfigurieren Sie NSG-Regeln, um Datenverkehr innerhalb des virtuellen Netzwerks auf dem PostgreSQL-Port zuzulassen.
  • Für die Azure Database for PostgreSQL-Instanz sind keine anderen Firewallregeln erforderlich, da der Datenverkehr intern im virtuellen Netzwerk ist.

Szenario 6: Azure Database for PostgreSQL – Einzelserver zu in VNet integrierter Instanz von Azure Database for PostgreSQL – 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, müssen Sie den Einzelserver so konfigurieren, dass Verbindungen von dem Subnetz, in dem der flexible Server bereitgestellt wird, zugelassen werden. Es folgt eine kurze Übersicht über die Schritte zum Einrichten dieser Konnektivität:

Hinzufügen einer VNet-Regel zum Einzelserver:

  • Navigieren Sie zum Azure-Portal, und öffnen Sie Ihre PostgreSQL-Einzelserverinstanz.

  • Wechseln Sie zu den Einstellungen für „Verbindungssicherheit“.

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

  • So können Sie angeben, welches virtuelle Netzwerk eine Verbindung mit Ihrem Einzelserver herstellen kann.

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

Regeleinstellungen konfigurieren:

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

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

  • Wählen Sie das virtuelle Netzwerk (VNet) und das dem flexiblen Server zugeordnete Subnetz aus.

  • Wählen Sie „OK“ aus, um die Einstellungen zu bestätigen.

    Screenshot: Zulassen des flexiblen Serversubnetzes

Nach Abschluss dieser Schritte wird der Einzelserver so konfiguriert, dass Verbindungen vom Subnetz des flexiblen Servers akzeptiert werden, sodass eine sichere Kommunikation zwischen den beiden Servern ermöglicht wird.

Szenario 7: Azure Database for PostgreSQL – Einzelserver mit privatem Endpunkt zu in VNet integrierte Instanz von Azure Database for PostgreSQL – Flexibler Server

Führen Sie die folgenden Schritte aus, um die Konnektivität von Azure Database for PostgreSQL – Einzelserver mit einem privaten Endpunkt zu einem in ein VNet integrierten flexiblen Server zu erleichtern:

Angeben von Details zum privaten Endpunkt:

  • Navigieren Sie im Azure-Portal zu der Einzelserverinstanz, und wählen Sie den privaten Endpunkt aus, um die zugehörigen VNet- und Subnetzdetails anzuzeigen.

  • Öffnen Sie das Blatt „Netzwerk“ des flexiblen Servers, und notieren Sie sich die VNet- und Subnetzinformationen.

    Screenshot eines Einzelservers, der über private Endpunkte verbunden ist.

    Screenshot: VNet- und Subnetzdetails des privaten Endpunkts des Einzelservers

Bewerten der VNet-Peeringanforderungen

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

Konfiguration der privaten DNS-Zone

  • Navigieren Sie zur Seite Netzwerk für den flexiblen Server, und überprüfen Sie, ob eine private DNS-Zone verwendet wird. Falls ja, öffnen Sie diese private DNS-Zone im Portal. Wählen Sie im linken Bereich die Option Verknüpfungen virtueller Netzwerke aus, und überprüfen Sie, ob das virtuelle Netzwerk des Einzelservers und des flexiblen Servers dieser Liste hinzugefügt wurde.

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

Wählen Sie andernfalls 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.

  • Navigieren Sie zum privaten Endpunkt für Ihren Einzelserver, und wählen Sie die Seite 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, der eine private DNS-Zone zeigt, die in einem privaten Endpunkt verwendet wird.

  • Wählen Sie die private DNS-Zone für den privaten Endpunkt Ihres Einzelservers aus, und überprüfen Sie, ob die VNets des Einzelservers und des flexiblen Servers den VNet-Verknüpfungen hinzugefügt wurden. Falls nicht, gehen Sie wie im obigen Schritt beschrieben vor, um die Verknüpfungen mit den virtuellen Netzwerken des Einzelservers und des flexiblen Servers zu dieser privaten DNS-Zone hinzuzufügen.

  • 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-Eintrag für Ihren Einzelserver vorhanden ist, der auf eine private IP-Adresse verweist.

    Screenshot, der eine private IP-Adresse zeigt, 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.

Szenario 8: Azure Database for PostgreSQL – Einzelserver mit privatem Endpunkt zu Azure Database for PostgreSQL – Flexibler Server mit privatem Endpunkt

Hier finden Sie die wesentlichen Netzwerkschritte für die Migration von einem Einzelserver mit einem privaten Endpunkt zu einem flexiblen Server mit einem privaten Endpunkt in Azure PostgreSQL, einschließlich der Integration des virtuellen Netzwerks eines Runtimeservers in Konfigurationen des privaten Endpunkts. Weitere Informationen zum Runtimeserver finden Sie im Artikel zum Runtimeserver für die Migration.

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

    • Navigieren Sie im Azure-Portal zur Instanz von Azure Database for PostgreSQL – Einzelserver.
    • 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.

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

    Screenshot: Flexibler Server mit privatem Endpunkt

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

    • Navigieren Sie im Azure-Portal zum Runtimeserver für die Migration – also zur in das VNet integrierten Instanz von Azure Database for PostgreSQL – Flexibler Server.
    • Erfassen Sie die VNet- und Subnetzdetails, die unter dem virtuellen Netzwerk aufgeführt sind.

    Screenshot: Runtimeserver für die Migration mit virtuellem Netzwerk

  • Bewerten der VNet-Peeringanforderungen

    • Aktivieren Sie das Peering virtueller Netzwerke, wenn sich die Server in unterschiedlichen VNets befinden. Peering ist nicht erforderlich, wenn sie sich in unterschiedlichen Subnetzen des gleichen virtuellen Netzwerks befinden.
    • Stellen Sie sicher, dass der Datenverkehr zwischen dem Quellserver, dem Runtimeserver für die Migration und dem Zielserver durch keine NSGs blockiert wird.
  • Konfiguration der privaten DNS-Zone

    • Vergewissern Sie sich auf der Netzwerkseite des Runtimeservers für die Migration, dass eine private DNS-Zone verwendet wird.
    • Stellen Sie sicher, dass sowohl das Quell-VNet von Azure Database for PostgreSQL – Einzelserver als auch das Ziel-VNet von Azure Database for PostgreSQL – Flexibler Server mit der privaten DNS-Zone des Runtimeservers für die Migration verknüpft ist.

    Screenshot: Private DNS-Zone des Runtimeservers

    • Fügen Sie eine private DNS-Zone an den privaten Endpunkt des Einzelservers an, sofern noch nicht konfiguriert.
    • Fügen Sie der privaten DNS-Zone VNet-Verknüpfungen für den Einzelserver und für den Runtimeserver für die Migration hinzu.
    • 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 des Quell-/Zielservers

Szenario 9: Lokale Umgebung, Azure-VM oder AWS RDS mit privaten IP-Adressen zu Azure Database for PostgreSQL – Flexibler Server mit privatem Endpunkt

Hier finden Sie die Netzwerkschritte für die Migration einer PostgreSQL-Datenbank von einer lokalen Umgebung, einer Azure-VM oder einer AWS-Instanz (jeweils konfiguriert mit privaten IP-Adressen) zu einer Instanz von Azure Database for PostgreSQL – Flexibler Server, die mit einem privaten Endpunkt geschützt ist. Durch die Migration wird eine sichere Datenübertragung innerhalb eines privaten Netzwerkraums sichergestellt. Für lokale Verbindungen wird dabei das VPN oder ExpressRoute von Azure verwendet, während für Cloud-zu-Cloud-Migrationen das Peering virtueller Netzwerke oder das VPN verwendet wird. Weitere Informationen zum Runtimeserver finden Sie im Artikel zum Runtimeserver für die Migration.

  • Herstellen der Netzwerkverbindung:

    • 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.
    • Stellen Sie für Azure-VMs oder AWS-Instanzen sicher, dass das Peering virtueller Netzwerke, ein VPN-Gateway oder eine ExpressRoute-Verbindung 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.

    • Navigieren Sie im Azure-Portal zum Runtimeserver für die Migration – also zur in das VNet integrierten Instanz von Azure Database for PostgreSQL – Flexibler Server.
    • Erfassen Sie die VNet- und Subnetzdetails, die unter dem virtuellen Netzwerk aufgeführt sind.
  • Bewerten der VNet-Peeringanforderungen

    • Aktivieren Sie das Peering virtueller Netzwerke, wenn sich die Server in unterschiedlichen VNets befinden. Peering ist nicht erforderlich, wenn sie sich in unterschiedlichen Subnetzen des gleichen virtuellen Netzwerks befinden.
    • Stellen Sie sicher, dass der Datenverkehr zwischen dem Quellserver, dem Runtimeserver für die Migration und dem Zielserver nicht durch NSGs blockiert wird.
  • Konfiguration der privaten DNS-Zone

    • Vergewissern Sie sich auf der Netzwerkseite des Runtimeservers für die Migration, dass eine private DNS-Zone verwendet wird.
    • Stellen Sie sicher, dass sowohl das Quell-VNet als auch das Ziel-VNet von Azure Database for PostgreSQL – Flexibler Server mit der privaten DNS-Zone des Runtimeservers für die Migration verknüpft ist.
    • Fügen Sie eine private DNS-Zone an den privaten Endpunkt des flexiblen Servers an, sofern noch nicht konfiguriert.
    • 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.

Ressourcen für die Netzwerkeinrichtung