Freigeben über

Netzwerk mit privatem Zugriff (Virtual Network-Integration) für Azure Database for PostgreSQL für PostgreSQ – Flexible Server

  • Artikel

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

In diesem Artikel werden die Konnektivitäts- und Netzwerkkonzepte für Azure Database for PostgreSQL – Flexible Server beschrieben.

Wenn Sie eine einen flexiblen Server für Azure Database for 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 einen flexiblen Server von Azure Database for PostgreSQL in Ihrem virtuellen Azure-Netzwerk mithilfe der Virtual Network-Einschleusung bereitstellen. Virtuelle Azure-Netzwerke ermöglichen eine private und sichere Netzwerkkommunikation. Ressourcen in einem VNet können über private IP-Adressen kommunizieren, die in diesem Netzwerk zugewiesen wurden.

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

  • Verbinden Sie Azure-Ressourcen im gleichen virtuellen Netzwerk über private IP-Adressen mit Ihrer Instanz von „Azure Database for PostgreSQL – Flexible Server“.
  • Herstellen einer Verbindung von Azure-externen Ressourcen mit Ihrer „Azure Database for PostgreSQL – Flexible Server“ über ein VPN oder eine Azure ExpressRoute-Verbindung.
  • Stellen Sie sicher, dass der flexible Server von Azure Database for PostgreSQL keinen öffentlichen Endpunkt aufweist, auf den über das Internet zugegriffen werden kann.

Abbildung der Funktionsweise von Peering zwischen virtuellen Netzwerken, von denen eines einen Azure Database for PostgreSQL – Flexibler Server enthält.

Im obigen Diagramm ist Folgendes zu sehen:

  • Azure Database for PostgreSQL – Flexible Server werden 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 for PostgreSQL – Flexible Server von PostgreSQL zugreifen.
  • Anwendungen, die in einem anderen virtuellen Netzwerk (VNet-2) bereitgestellt werden, haben keinen direkten Zugriff auf Azure Database for PostgreSQL – Flexible Server. Sie können erst nach einem Peering virtueller Netzwerke für eine private DNS-Zone auf die flexiblen Server zugreifen.

Virtuelle Netzwerke: Konzepte

Ein virtuelles Azure-Netzwerk (VNet) enthält einen privaten IP-Adressraum, der für Ihre Verwendung konfiguriert ist. Ihr virtuelles Netzwerk muss sich in derselben Azure-Region wie Ihre Azure Database for PostgreSQL – Flexible Server befinden. Weitere Informationen zu virtuellen Netzwerken finden Sie unter Übersicht über Azure Virtual Network.

Nachstehend werden einige Konzepte erläutert, die Sie kennen sollten, wenn Sie virtuelle Netzwerke verwenden, bei denen Ressourcen mit Azure Database for PostgreSQL – Flexible Servern in das virtuelle Netzwerk integriert sind:

  • Delegiertes Subnetz: Ein virtuelles Netzwerk enthält Subnetze. Subnetze bieten Ihnen die Möglichkeit, Ihr virtuelles Netzwerk in kleinere Adressräume einzuteilen. Azure-Ressourcen werden in bestimmten Subnetzen innerhalb eines virtuellen Netzwerks bereitgestellt.

    Ihre in einem virtuellen Netzwerk integrierte Azure Database for PostgreSQL – Flexible Server muss sich in einem Subnetz befinden, das delegiert ist. Das heißt, nur Azure Database for PostgreSQL – Flexible Server können 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. Dadurch bleiben 11 verfügbare IP-Adressen für einen CIDR-Bereich /28 verfügbar. Ein einzelner Azure Database for PostgreSQL-flexibler Server mit Features mit hoher Verfügbarkeit 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 dem Subnetzbereich von Azure Database for PostgreSQL – Flexible Server entspricht, und den nächsten Hop Virtual Network.

    Wichtig

    Die Namen AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet und GatewaySubnet sind in Azure reserviert. Verwenden Sie keinen dieser Namen als Ihren Subnetznamen.

  • 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 werden keine NSGs unterstützt, bei denen eine ASG Teil der Regel mit Azure Database for PostgreSQL – Flexibler Server ist. Es wird derzeit empfohlen, die IP-basierte Filterung von Quelle oder Ziel in einer NSG zu verwenden.

    Hochverfügbarkeit und andere Features von Azure Database for PostgreSQL – Flexible Server erfordern die Möglichkeit zum Senden/Empfangen von Datenverkehr an den Zielport 5432 im Subnetz des virtuellen Azure-Netzwerks, in dem Azure Database for PostgreSQL – Flexible Server bereitgestellt wird, sowie an Azure Storage zur Protokollarchivierung. Wenn Sie NSG erstellen, um den Datenverkehr zu oder von Ihrem Azure Database for PostgreSQL – Flexible Server in dem Subnetz, in dem sie bereitgestellt wird, zu unterbinden, sorgen Sie dafür, dass der Datenverkehr zum Zielport 5432 im Subnetz und auch zu Azure Storage zugelassen wird. Zu diesem Zweck müssen Sie das Diensttag „Azure Storage“ als Ziel angeben.

    Sie können diese Ausnahmeregel weiter filtern, indem Sie Ihre Azure-Region der Bezeichnung wie us-east.storage hinzufügen. Wenn Sie sich außerdem für die Verwendung der Microsoft Entra-Authentifizierung zum Authentifizieren von Anmeldedaten bei Ihrem Azure Database for PostgreSQL – Flexible Server entscheiden, lassen Sie ausgehenden Datenverkehr an Microsoft Entra ID mithilfe des Microsoft Entra-Diensttags zu.

    Beim Einrichten von Lesereplikaten über Azure-Regionen hinweg erfordert Azure Database for PostgreSQL – Flexible Server die Möglichkeit, Datenverkehr sowohl für primäre als auch Replikate an den Zielport 5432 zu senden oder zu empfangen, und zwar sowohl vom primären Server als auch vom Replikatserver an Azure-Speicher in primären und Replikatregionen. Der erforderliche TCP-Zielport für Storage ist 443.

  • Privates DNS Zonenintegration: Mit der Integration privater Azure-DNS-Zonen können Sie das private DNS innerhalb des aktuellen virtuellen Netzwerks oder eines beliebigen regionsinternen virtuellen Netzwerks mit Peering auflösen, in dem die private DNS-Zone verknüpft ist.

Verwenden einer privaten DNS-Zone

Privates DNS von Azure 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, ist die Bereitstellung der Informationen zur privaten DNS-Zone obligatorisch, um die DNS-Auflösung durchführen zu können. Bei der Erstellung einer neuen Azure Database for PostgreSQL – Flexible Server mit privatem Netzwerkzugriff müssen private DNS-Zonen verwendet werden, während die Azure Database for PostgreSQL – Flexible Server mit privatem Zugriff konfiguriert werden.

Wichtig

Wenn Sie eine private DNS-Zone in einem anderen Abonnement verwenden, muss dieses Abonnement auch den Microsoft.DBforPostgreSQL-Ressourcenanbieter registriert haben, andernfalls wird Ihre Bereitstellung von Azure Database for PostgreSQL flexible Server nicht abgeschlossen.

Für die Erstellung eines neuen Azure Database for PostgreSQL-flexiblen Servers mithilfe des privaten Netzwerkzugriffs mit einer API, einer Azure Resource Manager-Vorlage (ARM-Vorlage) oder Terraform erstellen Sie Privates DNS-Zonen. Verwenden Sie diese Zonen beim Konfigurieren von Azure Database for PostgreSQL – Flexible Server mit privatem Zugriff. Weitere Informationen finden Sie unter REST-API-Spezifikationen für Azure.

Wenn Sie das Azure-Portal oder Azure CLI zum Erstellen von Azure Database for PostgreSQL – Flexible Server verwenden, können Sie den Namen einer privaten DNS-Zone angeben, die Sie zuvor in demselben oder einem anderen Abonnement erstellt haben, oder es wird automatisch eine private DNS-Standardzone in Ihrem Abonnement erstellt.

Wenn Sie eine Azure-API, eine ARM-Vorlage oder Terraform verwenden, erstellen Sie private DNS-Zonen, die auf .postgres.database.azure.com enden. Verwenden Sie diese Zonen beim Konfigurieren von Azure Database for PostgreSQL – Flexible Servern mit privatem Zugriff. 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.com verwenden, kann der Name nicht der Name sein, den Sie für einen Ihrer Azure Databases for PostgreSQL – Flexible Server verwenden, oder während der Bereitstellung erhalten Sie eine Fehlermeldung. Weitere Informationen finden Sie in der Übersicht über private DNS-Zonen.

Im Azure Portal, über die API, die Azure CLI oder mit ARM-Vorlage können Sie auch die beim Erstellen von Azure Database for PostgreSQL Flexibler Server angegebene private DNS-Zone in eine andere private DNS-Zone ändern, die im selben oder in einem an deren Abonnement vorhanden ist.

Wichtig

Die Möglichkeit, die private DNS-Zone von der, die Sie beim Erstellen Ihrer Azure Database for PostgreSQL – Flexible Server angegeben haben, in eine andere private DNS-Zone zu ändern, ist derzeit für Server mit aktivierter Funktion für hohe Verfügbarkeit 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.

Wichtig

Bei der Servererstellung für Azure Database for PostgreSQL – Flexible Server mit privatem Netzwerkzugriff 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 von Azure Database for PostgreSQL – Flexibler Server aufzulösen. Die IP-Adresse der Weiterleitung sollte 168.63.129.16 sein.

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

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 Azure Database for PostgreSQL – Flexible Server von einem Client herstellen möchten, der in einem anderen virtuellen Netzwerk aus derselben Region oder einer anderen Region bereitgestellt wird, müssen Sie Verknüpfung der privaten DNS-Zone mit dem virtuellen Netzwerk herstellen. Weitere Informationen finden Sie unter Verknüpfen des virtuellen Netzwerks.

Hinweis

Es können ausschließlich private DNS-Zonen verknüpft werden, deren Namen auf postgres.database.azure.com enden. Ihr DNS-Zonenname kann nicht mit Ihren Azure Database for PostgreSQL – Flexible Servern identisch sein. Andernfalls schlägt die Namensauflösung fehl.

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

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

Verwenden des Entwurfs für private Hub-and-Spoke-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 Spokes sind ebenfalls virtuelle Netzwerke in Azure, mit denen einzelne Workloads isoliert werden. 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:

  • Spokes sind direkt miteinander verbunden:Peerings virtueller Netzwerke oder VPN-Tunnel werden zwischen den virtuellen Spoke-Netzwerken erstellt, um eine direkte Konnektivität zu ermöglichen, ohne das virtuelle Hubnetzwerk zu durchqueren.
  • Spokes kommunizieren über eine Netzwerk-Appliance: Jedes Spoke virtuelle Netzwerk verfügt über einen 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.
  • Virtuelles Netzwerkgateway, das an das Hubnetzwerk angefügt ist und benutzerdefinierte Routen verwendet, um die Kommunikation zwischen den Spokes zu ermöglichen.

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

Mithilfe von Azure Virtual Network Manager können Sie für die zentrale Verwaltung von Konnektivitäts- und Sicherheitskontrollen neue Hub-and-Spoke-Topologien von virtuellen Netzwerken erstellen (bzw. für solche bereits vorhandenen Topologien ein Onboarding durchführen).

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 VNETs (einer davon verfügt über Azure Database for PostgreSQL – Flexible Server und einen anderen Anwendungsclient), die sich in verschiedenen Regionen befinden.

Es gibt mehrere Möglichkeiten, diese Konnektivität zu erreichen, einschließlich:

  • 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 ein Peering virtueller Netzwerke erfolgt, verarbeitet Azure auch das Routing automatisch 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. Die Netzwerk zu Netzwerk-Verbindung wird für ein VPN-Gateway eingerichtet. 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 – Flexible Server bietet zwei Methoden für Replikationen: Physische Replikation (d. h. Streaming) über ein integriertes Feature für „Lesereplikate“ und logische Replikation. Beide Methoden sind ideal für unterschiedliche Anwendungsfälle, und ein Benutzer kann je nach dem Endziel eine der beiden auswählen.

Die Replikation über Azure-Regionen hinweg mit separaten virtuellen Netzwerken in jeder Region erfordert Konnektivität über regionale virtuelle Netzwerkgrenzen hinweg, die über das Peering virtueller Netzwerke oder in Hub-and-Spoke-Architekturen über eine Netzwerkappliance bereitgestellt werden kann.

Standardmäßig ist der Bereich für die DNS-Namensauflösung auf ein virtuelles Netzwerk festgelegt. Ein beliebiger Client kann in einem virtuellen Netzwerk (VNET1) den FQDN für Azure Database for PostgreSQL – Flexible Server in einem anderen virtuellen Netzwerk (VNET2) nicht auflösen.

Zur Behebung dieses Problems müssen Sie sicherstellen, dass Clients in VNET1 auf die private DNS-Zone für Azure Database for PostgreSQL – Flexible Server zugreifen können. Fügen Sie Ihrem Azure Database for PostgreSQL – Flexible Server eine virtuelle Netzwerkverknüpfung mit der privaten DNS-Zone 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 der Azure Database for PostgreSQL – Flexible Server in einem virtuellen Netzwerk und Subnetz bereitgestellt wurde, können Sie diese nicht in ein anderes virtuelles Netzwerk oder Subnetz verschieben. Auch das VNet kann in keine andere Ressourcengruppe oder kein anderes Abonnement verschoben werden.
  • Die Subnetzgröße (Adressräume) kann nicht mehr erhöht werden, wenn bereits Ressourcen im Subnetz vorhanden sind.
  • In virtuellen Netzwerken eingefügte Ressourcen können standardmäßig nicht mit Private Link interagieren. Wenn Sie Private Link für private Netzwerke verwenden möchten, lesen Sie Azure Database for PostgreSQL – Flexible Servernetzwerke mit Private Link.

Wichtig

Der 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. Es gibt zwei Arten von Ressourcensperren CanNotDelete und ReadOnly. Diese Arten von Sperren können entweder auf eine private DNS-Zone oder auf einen einzelnen Eintragssatz angewendet werden.

Das Anwenden einer Sperre von einem der beiden Typen auf private DNS-Zonen oder eine einzelne Datensatzgruppe kann die Fähigkeit von Azure Database for PostgreSQL – Flexible Server beeinträchtigen, DNS-Einträge zu aktualisieren. Darüber hinaus kann dies bei wichtigen Vorgängen im DNS (z. B. Hochverfügbarkeitsfailover vom primären zum sekundären Server) Probleme verursachen. Stellen Sie daher sicher, dass Sie keine Sperren für private DNS-Zonen oder Datensätze verwenden, wenn Sie Hochverfügbarkeitsfeatures mit Azure Database for PostgreSQL – Flexible Server nutzen.

Hostname

Unabhängig von Ihrer Netzwerkoption empfiehlt es sich, beim Herstellen einer Verbindung mit Ihrer Azure Database for PostgreSQL – Flexible Serverinstanz immer einen FQDN als Hostnamen zu verwenden. Es ist nicht gewährleistet, dass die IP-Adresse des Servers statisch bleibt. Mithilfe des FQDN können Sie verhindern, dass Änderungen an der Verbindungszeichenfolge vorgenommen werden.

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).

Zugehöriger Inhalt