Teilen über

Netzwerk mit privatem Zugriff (Virtual Network Integration) für Azure-Datenbank für PostgreSQL

In diesem Artikel werden Konnektivitäts- und Netzwerkkonzepte für Azure Database für flexible Serverinstanzen von PostgreSQL beschrieben.

Wenn Sie eine Azure-Datenbank für eine flexible Serverinstanz für PostgreSQL erstellen, müssen Sie eine der folgenden Netzwerkoptionen auswählen:

  • Privater Zugriff (VNet-Integration)
  • Öffentlicher Zugriff (zulässige IP-Adressen) und privater Endpunkt

In diesem Dokument werden Netzwerkoptionen für Privater Zugriff (Virtual Network-Integration) beschrieben.

Privater Zugriff (VNet-Integration)

Sie können eine Azure-Datenbank für PostgreSQL flexible Server-Instanz in Ihrem virtuellen Azure-Netzwerk bereitstellen, indem Sie eine virtuelle Netzwerk-Injektion verwenden. Virtuelle Azure-Netzwerke ermöglichen eine private und sichere Netzwerkkommunikation. Ressourcen in einem virtuellen Netzwerk kommunizieren über private IP-Adressen, die Sie in diesem Netzwerk zuweisen.

Diese Netzwerkoption bietet sich an, wenn Sie die folgenden Funktionen benötigen:

  • Verbinden Sie Azure-Ressourcen im selben virtuellen Netzwerk mit Ihrer Azure Database for PostgreSQL Flexible Server-Instanz über private IP-Adressen.
  • Verwenden Sie ein VPN oder Azure ExpressRoute, um eine Verbindung von Nicht-Azure-Ressourcen mit Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL herzustellen.
  • Stellen Sie sicher, dass die flexible Serverinstanz der Azure-Datenbank für PostgreSQL keinen öffentlichen Endpunkt aufweist, auf den über das Internet zugegriffen werden kann.

Diagramm, das zeigt, wie Peering zwischen virtuellen Netzwerken funktioniert, eines davon enthält eine Azure-Datenbank für PostgreSQL flexible Serverinstanz.

Im obigen Diagramm ist Folgendes zu sehen:

  • Azure Database for PostgreSQL Flexible Server Instanzen wird in Subnetz 10.0.1.0/24 des virtuellen VNet-1-Netzwerks eingefügt.
  • Anwendungen, die in verschiedenen Subnetzen innerhalb desselben virtuellen Netzwerks bereitgestellt werden, können direkt auf Azure Database für flexible Serverinstanzen von PostgreSQL zugreifen.
  • Anwendungen, die in einem anderen virtuellen Netzwerk (VNet-2) bereitgestellt werden, haben keinen direkten Zugriff auf Azure Database für flexible Serverinstanzen von PostgreSQL. Sie müssen virtuelles Netzwerk-Peering für eine private DNS-Zone durchführen, bevor sie auf die flexible Serverinstanz zugreifen können.

Virtuelle Netzwerke: Konzepte

Ein virtuelles Azure-Netzwerk enthält einen privaten IP-Adressraum, den Sie für Ihre Verwendung konfigurieren. Ihr virtuelles Netzwerk muss sich in derselben Azure-Region wie Ihre Azure-Datenbank für flexible Serverinstanz von PostgreSQL befinden. Weitere Informationen zu virtuellen Netzwerken finden Sie unter Übersicht über Azure Virtual Network.

Machen Sie sich mit diesen Konzepten vertraut, wenn Sie virtuelle Netzwerke verwenden, in denen Ressourcen in ein virtuelles Netzwerk mit Azure Database for PostgreSQL flexible Serverinstanzen integriert sind:

  • Delegiertes Subnetz: Ein virtuelles Netzwerk enthält Subnetze. Subnetze bieten Ihnen die Möglichkeit, Ihr virtuelles Netzwerk in kleinere Adressräume einzuteilen. Sie stellen Azure-Ressourcen in bestimmten Subnetzen in einem virtuellen Netzwerk bereit.

    Ihre Azure-Datenbank für PostgreSQL flexible Serverinstanz, die in ein virtuelles Netzwerk integriert ist, muss sich in einem subnetz befinden, das delegiert ist. Das heißt, nur Azure Database für flexible Serverinstanzen von PostgreSQL kann dieses Subnetz verwenden. Im delegierten Subnetz können sich keine anderen Azure-Ressourcentypen befinden. Sie delegieren ein Subnetz, indem Sie seine Delegierungseigenschaft mit Microsoft.DBforPostgreSQL/flexibleServers zuweisen.

    Der kleinste CIDR-Bereich, den Sie angeben können, ist /28, der 16 IP-Adressen für das Subnetz bereitstellt. Die erste und letzte Adresse in einem Netzwerk oder Subnetz kann keinem einzelnen Host zugewiesen werden. Azure reserviert fünf IP-Adressen, die intern vom Azure-Netzwerk genutzt werden, davon – wie oben erwähnt – zwei IP-Adressen, die keinem Host zugewiesen werden können. Diese Reservierung lässt Ihnen 11 verfügbare IP-Adressen für einen /28 CIDR-Bereich. Eine einzelne Azure-Datenbank für eine flexible PostgreSQL-Serverinstanz mit Hochverfügbarkeitsfunktionen verwendet vier Adressen.

    Stellen Sie bei Replikations- und Microsoft Entra-Verbindungen sicher, dass Routingtabellen keinen Einfluss auf den Datenverkehr haben. Ein gängiges Muster besteht darin, den gesamten ausgehenden Datenverkehr über eine Azure-Firewall oder eine benutzerdefinierte lokale Netzwerkfilterungs-Appliance weiterzuleiten.

    Wenn das Subnetz über eine Routentabelle verfügt, die der Regel zugeordnet ist, den gesamten Datenverkehr an ein virtuelles Gerät weiterzuleiten:

    • Fügen Sie eine Regel mit dem Ziel-Diensttag AzureActiveDirectory und dem nächsten Hop hinzu Internet.
    • Fügen Sie eine Regel mit dem Ziel-IP-Bereich hinzu, der mit dem Subnetzbereich der flexiblen Serverinstanz von Azure Database for PostgreSQL übereinstimmt, und den nächsten Hop Virtual Network.

    Von Bedeutung

    Die Namen AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet und GatewaySubnet sind in Azure reserviert. Verwenden Sie keinen dieser Namen als Ihren Subnetznamen. Darüber hinaus sollten virtuelle Netzwerke keinen überlappenden Adressraum zum Erstellen von regionsübergreifenden Replikaten haben.

  • Netzwerksicherheitsgruppe (NSG): Mit Sicherheitsregeln in Netzwerksicherheitsgruppen können Sie den Typ des ein- und ausgehenden Netzwerkdatenverkehrs von Subnetzen virtueller Netzwerke und Netzwerkschnittstellen filtern. Weitere Informationen finden Sie in der Übersicht über Netzwerksicherheitsgruppen.

    Anwendungssicherheitsgruppen (ASGs) vereinfachen die Steuerung der Sicherheit auf Schicht 4 mithilfe von NSGs für flache Netzwerke. Folgendes können Sie damit schnell ausführen:

    • Verknüpfen von VMs mit einer ASG oder Entfernen von VMs aus einer ASG.
    • Dynamisches Anwenden von Regeln auf diese VMs oder Entfernen von Regeln für diese VMs.

    Weitere Informationen finden Sie in der Übersicht über ASGs.

    Derzeit unterstützen Azure Database for PostgreSQL flexible Serverinstanzen keine NSGs, bei denen eine ASG Teil der Regel ist. Verwenden Sie die IP-basierte Quell- oder Zielfilterung in einer NSG.

    Hohe Verfügbarkeit und andere Features von Azure Database für PostgreSQL-Server erfordern die Möglichkeit, Datenverkehr an den Zielport 5432 innerhalb des virtuellen Azure-Netzwerk-Subnetzes zu senden und zu empfangen, in dem eine flexible Azure-Serverinstanz für PostgreSQL bereitgestellt und an Azure Storage für die Protokollarchivierung bereitgestellt wird. Wenn Sie NSGs erstellen, um den Datenverkehr zu oder von Ihrer Azure-Datenbank für PostgreSQL Flexible Server in dem Subnetz zu verweigern, in dem sie bereitgestellt wird, stellen Sie sicher, dass der Datenverkehr innerhalb des Subnetzes zum Zielport 5432 und auch zum Speicher zugelassen wird, indem Sie das Service-Tag Storage als Ziel verwenden. Für hohe Verfügbarkeit ist es am besten, eine Microsoft-Lösung hinzuzufügen. Der Endpunkt des Speicherdiensts, da dadurch das korrekte Datenverkehrsrouting auf das Azure-Speicherkonto sichergestellt wird, das zum Hochladen von WAL-Dateien (Write Ahead Log) verwendet wird.

    Sie können diese Ausnahmeregel weiter filtern, indem Sie Ihre Azure-Region der Bezeichnung wie us-east.storage hinzufügen. Wenn Sie auch die Microsoft Entra-Authentifizierung verwenden, um Anmeldungen bei Ihrer flexiblen Azure-Datenbank für PostgreSQL zu authentifizieren, ermöglichen Sie ausgehenden Datenverkehr an Microsoft Entra-ID mithilfe eines Microsoft Entra-Diensttags.

    Wenn Sie Lesereplikate über Azure-Regionen hinweg einrichten, muss Ihre flexible Serverinstanz von Azure Database for PostgreSQL in der Lage sein, Datenverkehr an den Zielport 5432 sowohl für den Primär- als auch für den Replikatserver und an Azure Storage in Primär- und Replikatsregionen sowohl vom Primär- als auch vom Replikatserver zu senden oder zu empfangen. Der erforderliche TCP-Zielport für Storage ist 443.

  • Integration einer privaten DNS-Zone: Durch die Integration einer privaten Azure-DNS-Zone können Sie das private DNS innerhalb des aktuellen virtuellen Netzwerks oder eines beliebigen virtuellen Netzwerks in der Region auflösen, mit dem die private DNS-Zone verbunden ist.

Verwenden einer privaten DNS-Zone

Azure Private DNS bietet einen zuverlässigen und sicheren DNS-Dienst für Ihr virtuelles Netzwerk. Privates Azure-DNS verwaltet Domänennamen im virtuellen Netzwerk und löst diese auf, ohne dass eine benutzerdefinierte DNS-Lösung konfiguriert werden muss.

Wenn Sie den privaten Netzwerkzugriff mit einem virtuellen Azure-Netzwerk verwenden, müssen Sie die Informationen zur privaten DNS-Zone bereitstellen, um die DNS-Auflösung zu aktivieren. Für neue Azure-Datenbank für Flexible Serverinstanzen von PostgreSQL, die mit privatem Netzwerkzugriff erstellt wurden, müssen Sie private DNS-Zonen verwenden, während Sie Azure Database für Flexible Serverinstanzen mit privatem Zugriff konfigurieren.

Von Bedeutung

Wenn Sie eine private DNS-Zone in einem anderen Abonnement verwenden, muss der Microsoft.DBforPostgreSQL-Ressourcenanbieter in diesem Abonnement ebenfalls registriert sein. Andernfalls wird Ihre Bereitstellung einer Azure-Datenbank für Die flexible Serverinstanz von PostgreSQL nicht abgeschlossen.

Für neue flexible Serverinstanzen von Azure Database for PostgreSQL, die mithilfe des privaten Netzwerkzugriffs mit einer API, einer Azure Resource Manager-Vorlage (ARM-Vorlage), Bicep oder Terraform erstellt wurden, erstellen Sie private DNS-Zonen. Verwenden Sie sie dann, während Sie die Azure Database für PostgreSQL-Flexible Serverinstanzen mit privatem Zugriff konfigurieren. Weitere Informationen finden Sie in den REST-API-Spezifikationen für Azure.

Wenn Sie das Azure-Portal oder die Azure CLI zum Erstellen der Azure-Datenbank für flexible Serverinstanzen von PostgreSQL verwenden, können Sie einen privaten DNS-Zonennamen angeben, den Sie zuvor in demselben oder einem anderen Abonnement erstellt haben, oder eine standardmäßige private DNS-Zone wird automatisch in Ihrem Abonnement erstellt.

Wenn Sie eine Azure-API, eine ARM-Vorlage, Bicep oder Terraform verwenden, sollten Sie private DNS-Zonen erstellen, die mit .postgres.database.azure.com enden. Verwenden Sie diese Zonen, während Sie Azure Database für flexible Serverinstanzen mit privatem Zugriff konfigurieren. Verwenden Sie beispielsweise das Formular [name1].[name2].postgres.database.azure.com oder [name].postgres.database.azure.com. Wenn Sie das Formular [name].postgres.database.azure.comverwenden, kann der Name nicht der Name sein, den Sie für eine Ihrer Azure-Datenbanken für flexible Serverinstanzen von PostgreSQL verwenden, oder Sie erhalten während der Bereitstellung eine Fehlermeldung. Weitere Informationen finden Sie in der Übersicht über private DNS-Zonen.

Wenn Sie das Azure-Portal, die APIs, die Azure CLI oder eine ARM-Vorlage verwenden, können Sie auch die Private DNS-Zone von der Zone ändern, die Sie beim Erstellen Ihrer Azure-Datenbank für Flexible Serverinstanz für PostgreSQL in eine andere private DNS-Zone erstellt haben, die im selben oder anderen Abonnement vorhanden ist.

Von Bedeutung

Die Möglichkeit, eine private DNS-Zone von der Zone zu ändern, die Sie beim Erstellen Ihrer Azure-Datenbank für die flexible Serverinstanz für PostgreSQL in eine andere private DNS-Zone angegeben haben, ist derzeit für Server mit aktivierter Hochverfügbarkeitsfunktion deaktiviert.

Nachdem Sie eine private Azure DNS-Zone erstellt haben, müssen Sie ein virtuelles Netzwerk damit verknüpfen. In diesem virtuellen Netzwerk gehostete Ressourcen können dann auf die private DNS-Zone zugreifen.

Von Bedeutung

Bei der Servererstellung für flexible Serverinstanzen von Azure Database for PostgreSQL mit privatem Netzwerk wird das Vorhandensein von virtuellen Netzwerkverknüpfungen nicht mehr überprüft. Beim Erstellen eines Servers über das Portal bieten wir die Möglichkeit, eine Verknüpfung zur Servererstellung über das Kontrollkästchen Private DNS-Zone mit Ihrem virtuellen Netzwerk verknüpfen im Azure Portal zu erstellen.

Private DNS-Zonen sind resilient gegenüber regionalen Ausfällen, da die Zonendaten global verfügbar sind. Die Ressourcendatensätze in einer privaten Zone werden automatisch regionsübergreifend repliziert. Azure Privates DNS ist ein grundlegender, zonenredundanter Verfügbarkeitszonendienst. Weitere Informationen dazu finden Sie unter Unterstützung von Verfügbarkeitszonen für Azure-Dienste.

Integration mit einem benutzerdefinierten DNS-Server

Wenn Sie einen benutzerdefinierten DNS-Server verwenden, müssen Sie eine DNS-Weiterleitung verwenden, um den FQDN Ihrer Azure Database for PostgreSQL Flexible Server-Instanz aufzulösen. Die IP-Adresse der Weiterleitung sollte 168.63.129.16 sein.

Der benutzerdefinierte DNS-Server sollte sich innerhalb des virtuellen Netzwerks befinden oder über die DNS-Servereinstellung des virtuellen Netzwerks erreichbar sein. Weitere Informationen finden Sie unter Namensauflösung mithilfe eines eigenen DNS-Servers.

Von Bedeutung

Geplante Wartungsupgrades aktualisieren ihre benutzerdefinierten DNS-Servereinstellungen automatisch. Um aktualisierte benutzerdefinierte DNS-Einstellungen vor dem nächsten geplanten Upgrade zu erkennen und anzuwenden, muss Microsoft die Aktualisierung intern ausführen, da diese Funktionalität nicht über kundenorientierte APIs oder Steuerelemente verfügbar gemacht wird. Wenn die Änderung früher wirksam werden muss, wenden Sie sich an den Microsoft-Support.

Private DNS-Zone und Peering virtueller Netzwerke

Die Einstellungen für private DNS-Zonen und das Peering virtueller Netzwerke sind voneinander unabhängig. Wenn Sie eine Verbindung mit der flexiblen Azure-Datenbank für PostgreSQL-Serverinstanz von einem Client herstellen möchten, den Sie in einem anderen virtuellen Netzwerk aus derselben Region oder einer anderen Region bereitstellen, müssen Sie die private DNS-Zone mit dem virtuellen Netzwerk verknüpfen . Weitere Informationen finden Sie unter Verknüpfen des virtuellen Netzwerks.

Hinweis

Sie können nur Private DNS-Zonennamen verknüpfen, die mit postgres.database.azure.com enden. Ihr DNS-Zonenname kann nicht mit Ihrer Azure-Datenbank für flexible Serverinstanzen von PostgreSQL übereinstimmen. Andernfalls schlägt die Namensauflösung fehl.

Um dem DNS-Eintrag einen Servernamen zuzuordnen, führen Sie den nslookup Befehl in Azure Cloud Shell mithilfe von Azure PowerShell oder Bash aus. Ersetzen Sie den Namen des Servers für den <server_name> Parameter im folgenden Beispiel:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Verwenden Sie das Hub-und-Spoke-Design für private Netzwerke

Hub-and-Spoke ist ein beliebtes Netzwerkmodell für die effiziente Verwaltung von allgemeinen Kommunikations- oder Sicherheitsanforderungen.

Der Hub ist ein virtuelles Netzwerk, das als Zentrale für die Verwaltung externer Konnektivitäts- und Hostingdienste dient. Er hostet außerdem Dienste, die von mehreren Workloads verwendet werden. Der Hub koordiniert die gesamte Kommunikation zwischen den Spokes. IT-Regeln oder Prozesse wie die Sicherheit können den Datenverkehr überprüfen, routen und zentral verwalten. Die Spokes sind virtuelle Netzwerke, die Workloads hosten und sich über ein Peering virtueller Netzwerke mit dem zentralen Hub verbinden. Gemeinsame Dienste werden in ihren eigenen Subnetzen zur gemeinsamen Nutzung mit den Spokes gehostet. Ein Umkreissubnetz fungiert dann als Sicherheitsappliance.

Die Speichen sind auch virtuelle Netzwerke in Azure, die Sie zum Isolieren einzelner Workloads verwenden. Der Datenverkehrsfluss zwischen dem lokalen Hauptsitz und Azure erfolgt über Azure ExpressRoute oder Site-to-Site-VPN, das mit dem virtuellen Netzwerk des Hubs verbunden ist. Die virtuellen Netzwerke von den Spokes zum Hub sind per Peering verbunden und ermöglichen die Kommunikation mit lokalen Ressourcen. Sie können den Hub und jede Spoke in separaten Abonnements oder Ressourcengruppen implementieren.

Es gibt drei Hauptmuster für die Verbindung von virtuellen Spoke-Netzwerken untereinander:

  • Speichen sind direkt miteinander verbunden: Sie erstellen virtuelle Netzwerk-Peerings oder VPN-Tunnel zwischen den virtuellen Speichennetzwerken, um direkte Konnektivität bereitzustellen, ohne das virtuelle Hubnetzwerk zu durchlaufen.
  • Spokes kommunizieren über eine Netzwerk-Appliance: Jedes virtuelle Spoke-Netzwerk verfügt über ein Peering zu einem virtuellen WAN oder zu einem virtuellen Hubnetzwerk. Eine Appliance leitet den Datenverkehr von Spoke zu Spoke weiter. Die Appliance kann von Microsoft (wie bei Virtual WAN) oder von Ihnen selbst verwaltet werden.
  • Ein virtuelles Netzwerkgateway, das an das Hubnetzwerk angefügt ist und benutzerdefinierte Routen verwendet: Ermöglicht die Kommunikation zwischen den Spokes.

Das Diagramm zeigt die grundlegende Hub-and-Spoke-Architektur mit Hybridkonnektivität über Express Hub.

Verwenden Sie Azure Virtual Network Manager, um neue Hub- und Spoke-Virtual-Network-Topologien zu erstellen (und bestehende einzubinden) für die zentrale Verwaltung von Konnektivitäts- und Sicherheitskontrollen.

Kommunikation mit privat vernetzten Clients in verschiedenen Regionen

Häufig müssen Kunden eine Verbindung mit Clients in verschiedenen Azure-Regionen herstellen. Genauer gesagt: Diese Frage bezieht sich in der Regel auf das Verbinden von zwei virtuellen Netzwerken (einer davon verfügt über eine flexible Azure-Datenbank für PostgreSQL-Serverinstanz und einen anderen über einen Anwendungsclient), die sich in verschiedenen Regionen befinden.

Sie können eine solche Konnektivität auf mehrere Arten erreichen, darunter:

  • Globales Peering virtueller Netzwerke. Die häufigste, da einfachste Methode, Netzwerke in verschiedenen Regionen miteinander zu verbinden. Das globale Peering virtueller Netzwerke erstellt eine Verbindung über den Azure-Backbone direkt zwischen den beiden Virtual Networks mit Peering. Diese Methode bietet den besten Netzwerkdurchsatz und die niedrigsten Latenzen für die Konnektivität. Wenn Sie virtuelle Netzwerke verbinden, übernimmt Azure auch automatisch das Routing für Sie. Diese virtuellen Netzwerke können mit allen Ressourcen im virtuellen Peernetzwerk kommunizieren, die auf einem VPN-Gateway eingerichtet sind.
  • Netzwerk-zu-Netzwerk-Verbindung. Eine Verbindung zwischen virtuellen Netzwerken (Netzwerk zu Netzwerk-Verbindung) ist im Wesentlichen ein VPN zwischen den beiden verschiedenen Azure-Standorten. Sie richten die Netzwerk-zu-Netzwerk-Verbindung auf einem VPN-Gateway ein. Ihr Datenverkehr verursacht zwei zusätzliche Datenverkehrs-Hops im Vergleich zum globalen Peering virtueller Netzwerke. Im Vergleich zu dieser Methode gibt es auch zusätzliche Latenz und geringere Bandbreite.
  • Kommunikation über Netzwerk-Appliance in der Hub- und Spoke-Architektur. Anstatt virtuelle Spoke-Netzwerke direkt miteinander zu verbinden, können Sie Netzwerkgeräte zur Weiterleitung des Datenverkehrs zwischen Spokes verwenden. Netzwerkgeräte bieten zusätzliche Dienste im Netzwerk wie eingehende Paketuntersuchung und Segmentierung oder Überwachung des Datenverkehrs, können aber Wartezeiten und Leistungsengpässe verursachen, wenn sie nicht richtig dimensioniert sind.

Replikation zwischen Azure-Regionen und virtuellen Netzwerken mit privatem Netzwerk

Bei der Datenbankreplikation werden Daten von einem zentralen oder primären Server auf mehrere Server kopiert, die als „Replikate“ bezeichnet werden. Der primäre Server akzeptiert Lese- und Schreibvorgänge, während die Replikate schreibgeschützte Transaktionen ausführen. Der primäre Server und die Replikate bilden gemeinsam ein Datenbankcluster. Ziel der Datenbankreplikation ist es, Redundanz, Konsistenz, hohe Verfügbarkeit und Barrierefreiheit von Daten sicherzustellen, insbesondere in besonders datenverkehrsintensiven, unternehmenskritischen Anwendungen.

Azure Database for PostgreSQL bietet zwei Methoden für Replikationen: physische (d. h. Streaming) über die integrierte Read Replica-Funktion und logische Replikation. Beide eignen sich ideal für unterschiedliche Anwendungsfälle, und Sie können je nach Endziel einen übereinander auswählen.

Die Replikation über Azure-Regionen mit separaten virtuellen Netzwerken in jeder Region erfordert Konnektivität über die Grenzen regionaler virtueller Netzwerke hinweg, die entweder durch virtuelles Netzwerk-Peering oder in Hub-and-Spoke-Architekturen über eine Netzwerk-Appliance bereitgestellt werden kann.

Standardmäßig ist der Bereich für die DNS-Namensauflösung auf ein virtuelles Netzwerk festgelegt. Kein Client in einem virtuellen Netzwerk (VNET1) kann den FQDN der flexiblen Serverinstanz der Azure-Datenbank für PostgreSQL in einem anderen virtuellen Netzwerk (VNET2) auflösen.

Um dieses Problem zu beheben, stellen Sie sicher, dass Clients in VNET1 auf die private DNS-Zone der Azure-Datenbank für PostgreSQL-Flexible-Serverinstanz zugreifen können. Fügen Sie eine virtuelle Netzwerkverbindung zur privaten DNS-Zone Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL hinzu.

Nicht unterstützte virtuelle Netzwerkszenarios

Hier finden Sie einige Einschränkungen bei der Arbeit mit virtuellen Netzwerken, die über die Virtual Network-Integration erstellt werden:

  • Nachdem Sie eine Azure-Datenbank für PostgreSQL flexible Serverinstanz in einem virtuellen Netzwerk und Subnetz bereitgestellt haben, können Sie sie nicht in ein anderes virtuelles Netzwerk oder Subnetz verschieben. Auch das VNet kann in keine andere Ressourcengruppe oder kein anderes Abonnement verschoben werden.
  • Sie können die Subnetzgröße (Adressräume) nicht erhöhen, nachdem Ressourcen im Subnetz vorhanden sind.
  • Standardmäßig können in das virtuelle Netzwerk eingefügte Ressourcen nicht mit privatem Link interagieren. Wenn Sie private Verknüpfungen für private Netzwerke verwenden möchten, lesen Sie Azure Database for PostgreSQL Networking with Private Link.

Von Bedeutung

Azure Resource Manager unterstützt die Möglichkeit, Ressourcen als Sicherheitssteuerung zu sperren. Ressourcensperren werden auf die Ressource angewendet und gelten für alle Benutzer und Rollen. Zwei Arten von Ressourcensperre sind vorhanden: CanNotDelete und ReadOnly. Sie können diese Sperrtypen entweder auf eine private DNS-Zone oder auf einen einzelnen Datensatzsatz anwenden.

Das Anwenden einer Sperre auf eine private DNS-Zone oder einen einzelnen Datensatz kann die Fähigkeit einer flexiblen Azure-Datenbank für eine PostgreSQL-Serverinstanz beeinträchtigen, DNS-Einträge zu aktualisieren. Es kann auch bei wichtigen DNS-Vorgängen Probleme verursachen, wie zum Beispiel beim Hochverfügbarkeits-Failover vom primären auf den sekundären Server. Stellen Sie aus diesen Gründen sicher, dass Sie keine private DNS-Zone oder Datensatzsperren verwenden, wenn Sie Hochverfügbarkeitsfeatures mit einer Azure-Datenbank für flexible Serverinstanz für PostgreSQL verwenden.

Hostname

Unabhängig von der von Ihnen gewählten Netzwerkoption verwenden Sie immer einen vollqualifizierten Domänennamen (FQDN) als Hostname, wenn Sie eine Verbindung mit Ihrer Azure-Datenbank für flexible Serverinstanz für PostgreSQL herstellen. Die IP-Adresse des Servers kann sich ändern. Mit dem FQDN müssen Sie ihre Verbindungszeichenfolge nicht aktualisieren.

Ein Beispiel, bei dem ein FQDN als Hostname verwendet wird, ist hostname = servername.postgres.database.azure.com. Vermeiden Sie nach Möglichkeit die Verwendung von hostname = 10.0.0.4 (eine private Adresse) oder hostname = 40.2.45.67 (eine öffentliche Adresse).

Verwandte Inhalte

  • Last updated on